Build Debate....
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
Hi guys : We recently refactored an application to have automated builds. Me and a coworker got in a heated argument about wether or not to use Maven and Ant. Our problem is that, the way our build works requires Maven and Ant to be installed on the classpath of developer machines .... This was frustrating to me because we are in a fast paced environment and we have relatively low resources and untrained developers, and we want scientists who might be relatively new to Java to contribute to our open source project. We want something that can basically be checked out from CVS and directly developed against, in any platform. For example, we don't want every developer to have to edit Unix configuration files, etc... just to develop on the project.
Is there any way to build a cross platform, automated build that doesnt require global installations of Ant and Maven ?
Also , another debate we got into was wether Maven was really necessary for our builds. Any thoughts on when not to and when to use Maven ?
Is there any way to build a cross platform, automated build that doesnt require global installations of Ant and Maven ?
Also , another debate we got into was wether Maven was really necessary for our builds. Any thoughts on when not to and when to use Maven ?
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
You could always include the necessary Ant files in your project and provide scripts (Windows .bat and Linux .sh files) that use your packaged Ant to build stuff. I have done that for a few projects and the JBoss AS source (5.1 and earlier) does it.
I imagine you could do the same with Maven.
I imagine you could do the same with Maven.
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
Any command-line tool needs to be on the path (*not* classpath), no matter what--that's how the OS knows how to run it.
Either can be used from within an IDE, some need to be configured, some IDEs have at least Ant support built-in.
Maven does a *lot* more than just simple builds. When it works, it's awesome. When it doesn't, it can be a real PITA. If you're just using it for dependency management, something like Ivy might be a less bitter pill to swallow; YMMV.
Either can be used from within an IDE, some need to be configured, some IDEs have at least Ant support built-in.
Maven does a *lot* more than just simple builds. When it works, it's awesome. When it doesn't, it can be a real PITA. If you're just using it for dependency management, something like Ivy might be a less bitter pill to swallow; YMMV.
jay vas
Ranch Hand
Posts: 407
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
Yeah... well I'm wondering --- why is maven so complicated to run on OS X ? I was told my system had a strange unix configuration that made the .bashrc file uneditable by users....
But looking online, I found that there is no simple on stop solution for installation of maven.
Is this a common issue ? Does Maven work the same on different OS's ?
Also ---- what happens if maven gets libraries that are new and untested ? Is there a way to control for this ?
But looking online, I found that there is no simple on stop solution for installation of maven.
Is this a common issue ? Does Maven work the same on different OS's ?
Also ---- what happens if maven gets libraries that are new and untested ? Is there a way to control for this ?
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
Maven is trivial to run on OS X; I didn't do anything special to make it run. Not sure why you'd have a problem. I think it's .bash_profile, though, but my MBP is currently MIA.
So no, it's not a common issue, and Maven is Java--it works the same across OSs, the primary difference being where the default repo is, your home directory, etc.
What do you mean if Maven gets libraries that are new and untested? *You* define the dependencies. If it gets a new, untested library, it's your own fault.
So no, it's not a common issue, and Maven is Java--it works the same across OSs, the primary difference being where the default repo is, your home directory, etc.
What do you mean if Maven gets libraries that are new and untested? *You* define the dependencies. If it gets a new, untested library, it's your own fault.
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
If you are dealing with Yet Another Cheap-and-Cheesy shop (sorry, but while I always appreciate economy, I see too much "economical" incompetence these days for my blood pressure's sake
), I'd say that Maven would be the better route.
Unless the OS is, in fact, fighting things, Maven is better for the slack-jawed masses. Essentially, you download Maven, unzip it, set 2 environment variables, pull in a representative Maven project and let it start sucking down the build resources. After the initial build, you can give the 15-rupee-an-hour folks a basic universal goal (like "mvn install") and leave them to commit the various atrocities that ignorant people do when supplied with complex tools that they don't understand.
Ant isn't really any harder to understand, but unless you complicate the setup by adding Ivy, it won't do automated fetches and installs of dependent features. So it requires 2, possibly 3 functional brain cells.
The other reason I'd recommend Maven is that Maven enforces a standardized project organization. It's not the one I would have made, but at least it's standard. So when you dump someone cold on a project, they will at least stand a chance of being able to locate stuff, know how it fits in, and how to build the project. Ant, on the other hand, allows you to lay out stuff any old way you like. Some people prefer the extra freedom, but freedom has its price, and it doesn't sound like your shop is interested in paying. Maven has its own price, but as long as you stick to bog-standard jars and webapps, you can dodge it.
Of course, in either case, someone there needs to understand the build system of choice. Not everyone can be someone whose prior experience was on the family farm. Lunch isn't free, no matter where you are or how you cut corners.
), I'd say that Maven would be the better route. Unless the OS is, in fact, fighting things, Maven is better for the slack-jawed masses. Essentially, you download Maven, unzip it, set 2 environment variables, pull in a representative Maven project and let it start sucking down the build resources. After the initial build, you can give the 15-rupee-an-hour folks a basic universal goal (like "mvn install") and leave them to commit the various atrocities that ignorant people do when supplied with complex tools that they don't understand.
Ant isn't really any harder to understand, but unless you complicate the setup by adding Ivy, it won't do automated fetches and installs of dependent features. So it requires 2, possibly 3 functional brain cells.
The other reason I'd recommend Maven is that Maven enforces a standardized project organization. It's not the one I would have made, but at least it's standard. So when you dump someone cold on a project, they will at least stand a chance of being able to locate stuff, know how it fits in, and how to build the project. Ant, on the other hand, allows you to lay out stuff any old way you like. Some people prefer the extra freedom, but freedom has its price, and it doesn't sound like your shop is interested in paying. Maven has its own price, but as long as you stick to bog-standard jars and webapps, you can dodge it.
Of course, in either case, someone there needs to understand the build system of choice. Not everyone can be someone whose prior experience was on the family farm. Lunch isn't free, no matter where you are or how you cut corners.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
@Tim: Scientists actually have brain cells, but apply them towards other endeavors besides programming or learning build tools. I'm okay with that, and understand the desire to have smart-people-but-not-developers be able to contribute.
posted 16 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
I missed the "scientists" part. I'll forgive them. I'm of the scientific persuasion myself, and I fully realize that scientists don't require about 99% of the programming skills that full-time IT people should have. Actually, I'd probably whip out the FORTRAN compiler if I was doing scientific programming even now. 10 statement types, a simple compile process, and tons of scientific and statistical support packages for the specialized needs. Java's not the best fit for down-and-dirty scientific stuff anyway, thanks to the floating-point considerations.
My gripe is with full-on IT shops that attempt to employ monkeys to do skilled labor. On my gloomier days, I run into more of them than the kind that actually have talent.
My gripe is with full-on IT shops that attempt to employ monkeys to do skilled labor. On my gloomier days, I run into more of them than the kind that actually have talent.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
| Could you hold this puppy for a sec? I need to adjust this tiny ad: Paul Wheaton's 16th Kickstarter: Gardening playing cards for gardeners and homesteaders https://coderanch.com/t/889615/Paul-Wheaton-Kickstarter-Gardening-playing |








