Hi folks,
after setting up and maintaining complex build environments using ANT
and Maven for a couple of years I have some thought about the topic
+) "a fool with a tool is still a fool" - if a complex build system is
falling apart it has most of the times nothing to do with the underlying
tools being used - if you do your job properly it will work
+) a related problem is that many companies hire juniors for this
setting up and maintaining a build system - it is not real programming
after all ... :-) ... later on the know better
+) "the complexity does not go away" - the complexity remains no matter
of the build system but it might be less visible - so if you have
problems they are hard to fix no matter what you are using
+) "once you have it you have it" - that was an important topic with my
current customer for rolling out a M2 build - it would be really
difficult and depressing to kick out M2 and replace it with something
else. And M2 is not really "undisputed" around here ... :-)
Cheers,
Siegfried Goeschl
Mykel Alvis wrote:
I agree with Graham's assessment that the bigger the project, the more
useful. However, it does come with a price. You've got to get used to the
idea of hard-versioning artifacts and moving toward controlled releases.
And a number of the plugins are pretty...interesting...to use.
I'm of the opinion that you shouldn't switch builds unless there's a
compelling reason to do so. If your scripted/ant build performs the build
tasks that you need, then use it until it becomes unmanageable or until you
need something else...like consistency and reporting. In every case that
I've installed maven in an enterprise environment, those are not just the
most compelling reasons that someone wanted/liked it. They WERE the
reasons. Ramp-up time for a new developer capable of building whatever
system and/or component needed dropped from several hours (even days) into
the 10's of minutes and is ridiculously easy. Likewise, the reporting
available to a maven build stands on its own. Anyone looking at the
default
generated reporting gets pretty excited, and when you can add other
sorts of
reports (we like JDepend, pmd, and Findbugs for example), it really shines.
As a side note, it has been my experience that low-to-mid-skill developers
rarely understands or wants to understand the software construction
process,
and management practically never does. Builds are a thing that are either
(a) laughably easy or (b) handled by someone else. If you're
implementing a
complex build, that someone is probably you. More than anything else, it
seems that resistance to a new (maven) build is inevitable since it forces
you to do some things that you might not otherwise do or to do them in a
particular way. Prepare for that.
As for scaling into large builds, I'd note that that a lot of that depends
on patterns in your code. For instance, we (now) have about 100 active
components being built, 80+ of which are in the hands of the coders (as
opposed to being built exclusively by the build engineer). Of those, they
can be divided out into about 15 classes of components. Once the build
process is defined for each class of components, then managing becomes
simpler for any new component of that class. For example, EJBs and their
clients are 2 classes of components in our systems. We can produce a build
for a new EJB in about 5 minutes and have a skeletal project waiting to be
checked out of SCM ready for the developer to write code.
If we had to manage 100 unique types of artifacts, this system would
definitely be less scalable, and I'd probably be wanting to go looking
for a
new job.
I haven't tried buildr, but am certainly interested in it. As for the
Maven
Uncertainty Principle they describe, I'm going to say that I've definitely
encountered that effect but it seems that we generally had no problem
defeating it with proper planning and project organization. Projects that
force maven to bend to the will of the project tend to be less successful
with maven integration than those that are structured around "the maven
way". Note that "the maven way" is much like "the DJB way". It's flexible
within limits, but you definitely get more bang for your buck if you
conform
to "the way".
Maven's definitely got it's warts, just like any product, and your mileage
for responses on the lists may vary, but it's my current tool-of-choice and
I've not regretted the decision to anywhere near the point of replacing it
yet.
On 5/8/07, Graham Leggett <[EMAIL PROTECTED]> wrote:
On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote:
> How does maven's declarative convention over configuration stack up
> against scripted solutions like buildr, groovy/ant or scons when it
> comes to maintenance costs for large projects?
{snip}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
