At 02:57 AM 12/24/2006, you wrote:
ANT:
If you want to be like most every over Java project in the world, use
Ant.  It works fine.  Just be sure to always remember: PROPERTIES ARE
IMMUTABLE.

MAVEN:
If you want to get a lot of extra bells and and whistles, such as
having all your dependencies automatically downloaded, versioned, and
shared outside of source control, and tons of built-in automated
reports and metrics, use Maven.  Be prepared for a big learning curve,
though.

Yea, I'll testify to that. I recently had the "opportunity" to use Maven (2)
on a project and it was er....trying. Fully half of the project
stumbling blocks were due to the difficulty of using Maven, our inexperience
with it, and the lack of good, well-organized documentation (IMHO the
Maven docs are "here a page, there a page, everywhere a page", lacking
structure and organization).

As an example of the kinds of problems that "high-level automation"
can bring....Our project needed to use some specific libraries that
came with the XXX software package. I figured out the Maven incantation
to correctly  'install' these libraries to our local repository using one
of the Maven FAQ pages. Soon after that, however, I found myself
debugging a problem in the XXX library source code. I'm looking at the source
code and saying "this error couldn't possibly happen given this
source code". Sure enough, Maven had downloaded some other
version of the library without our knowledge, even though our
POM files specified the exact version I had loaded by hand. Now, I assume,
that this kind of thing is controllable and preventable, if you know
which POM file option or configuration flag to use but, of course,
that's a big learning curve in itself.

Another example: our initial compile generated a local Maven repository
of 14M in size. After that, one of my colleagues accidentally
specified an incorrect library version number in a POM file and,
on the next compile, the library ballooned to 47 Meg, trashing
our ability to compile the program correctly. Easily corrected, though:
just blow away the local repository, reload all your local project-
specific libraries, and start over. :)

In summary, I haven't entirely given up on the idea of using Maven but,
in my little experience, it's gonna require a big learning curve.
Its usefulness will probably depend on the size of your project,
the availablility of repository files for the libraries you need, your
ability to re/structure your project in a way that makes Maven happy,
and your ability to come up to speed.

By contrast, it's awfully easy to point Ant at a library directory.

If you want to use Maven, be sure to download the free (with registration)
PDF e-book "Better Builds with Maven" available from  Mergere (which
I discovered only after my project :(

http://www.mergere.com/m2book_download.jsp



  As other posters mentioned, make sure you use Maven 2.

Definitely, if you can, but several open-source projects have
yet to be rewritten for Maven 2.
        good luck,
        -tom



  I
used to be a big fan of Maven 1, and used it a lot.  I even wrote an
open source plugins for it (for Emma).

However, I then stopped doing Java for a while, and during that time
Maven 2 came out.  Then, a few weeks ago, I pulled my Maven 1 project
off the shelf.  i couldn't even get the stupid thing to build.
External dependencies that used to be there in the "central Maven
repository" weren't.  They vanished off the face of the earth, because
they changed the organization of the repository for Maven 2.  Even
though I found some in individually hosted Maven 1 repositories, they
didn't have everything that the old central repository used to have,
and I was still missing enough stuff to be in dependency hell.  It
looks like the Maven folks were so impressed with themselves for
releasing Maven 2, they didn't even care about backward compatibility
for Maven 1.  Maybe this is a one time occurrence, but I've lost a lot
of faith in the product team because of this experience.

RAKE:
If you want to be ultracool cutting edge, use Rake.  It's a Ruby-based
build tool, and has all of the scriptable object-oriented goodness
that Ruby implies.  Also, with the popularity explosion of Ruby
(mainly due to Rails and David Hannemier-Hooha) you probably have as
much 3rd-party library support (RubyGems) as you do for Ant/Java.
There's even some tool called "Raven" that supposedly makes it easier
to use Rake for Java projects, but I've never played with it.

MAKE:
Well, it works.  Pretty much exactly the same as it did 15-20+ years
ago (or how much more?).  If that makes you feel comfortable and safe,
then go for it :)

-- Chad

On 12/23/06, Robert Zeigler <[EMAIL PROTECTED]> wrote:
Without starting a flame-war... ;)
I'm about to embark on updating a very brittle build process. It's
currently based on a combination of relying on the IDE + a bit of ant
In all honesty, I know make better than I know any other build tool, but
I'd rather not do this build in make. So, I'm looking for some input
into what build tool(s) you use, and why? Thanks!

Robert



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to