Maven vs. Scripted Build Systems

[Peter Kahn <ci...@gmail.com>]

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?  Is there anyone out there who is
involved with a large complex project who can weigh in on how sustainable
maven has been and how much work it has required to keep bit rot at bay?

I have a project with 20+ sub-projects which I'm planning to convert from a
home grown maven like system written in shell scripts and ant to maven.  It
seemed like a no brainer, the system's process matched maven's model quite
well.  Then I read these two pieces and while I disagree with them I need to
ask... "how sustainable is maven for large scale projects"

http://blog.labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-maven-blues/

http://blog.labnotes.org/2007/05/03/buildr-or-when-ruby-is-faster-than-java/

Scripted solution can be much more concise than declarative, but they can
also become very complex very quickly.  I'm of the belief that I can use or
misuse any technology and create a smoothly running system or a maintenance
nightmare.  I just want reassurance that maven doesn't have some hidden
cost, or how best to avoid the pitfalls if it does.

FYI, I already know about the Better Builds with Maven and the sonatype
books and am working my way through them.

Thanks for the help...


-- 
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM
http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/
Awareness - Intention - Action

Re: Maven vs. Scripted Build Systems

[Carlos Sanchez <ca...@apache.org>]

I like to compare it to pure JDBC vs. Object relational tools.

With OR you lose control of the small details but overall you get a
better, simpler solution, worrying on the aspects you really care
about

On 5/8/07, Graham Leggett <mi...@sharp.fm> 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?
>
> Scripted systems have an Achilles heel - build systems are not the primary
> task at hand in a large project, the code is. As a result scripted build
> systems are generally poorly designed and implemented, even though the
> tools on which they are built (like ant) are top notch quality. The
> scripted systems in every large project I've ever encountered were
> complex, incomprehensible, platform specific and incomplete, and
> ultimately thrown out.
>
> The standardisation efforts of maven save a fortune - in our case on a big
> project, releasing the project takes the form of "mvn release:prepare" and
> "mvn release:perform", and that is it. This means that any member of a
> project team can make a release, and that release will probably work first
> time, or fail for very clear and obvious reasons.
>
> > "how sustainable is maven for large scale projects"
>
> Implementing maven is not a walk in the park in a complex project.
>
> There are times when the classic maven design philosophy of "let maven
> figure this out for you" doesn't always hold true, meaning you have to
> understand enough about the build process to make sure things work
> together.
>
> Some of the maven plugins are not as reliable, or as complete than others.
>
> But - having implemented a maven build system, all the maven features,
> from release management, to documentation management, come for free. This
> investment in standardisation pays big dividends in the future.
>
> In short, the bigger the project, the more useful maven becomes.
>
> Regards,
> Graham
> --
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven vs. Scripted Build Systems

[Stephane Nicoll <st...@gmail.com>]

On 5/9/07, Graham Leggett <mi...@sharp.fm> wrote:
> let's use the maven way - something you learn once, and apply everywhere.
>

"Learn once, apply everywhere", that reminds me something :)

Maybe our next marketing slogan, who knows.

Stéphane


> Regards,
> Graham
> --
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven vs. Scripted Build Systems

[Graham Leggett <mi...@sharp.fm>]

On Wed, May 9, 2007 12:30 pm, Siegfried Goeschl wrote:

> +) 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

I've seen over an over again how a lack of basic software discipline can
reduce a quickly running project down to an absolute crawl.

One of the most key benefits of a system like maven is that it (within
limitations) enforces discipline within a project.

When you've made a policy decision that the maven release plugin (for
example) will be used to make releases, you are now implicitely saying
that the underlying code needs to build, the version control rules need to
be followed properly, the maven repository to which you're publishing
releases needs to be configured properly.

Instead of trying to educate developers on some weird home grown way of
maintaining software discipline (a task akin to herding cats), you say
let's use the maven way - something you learn once, and apply everywhere.

Regards,
Graham
--



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven vs. Scripted Build Systems

[Siegfried Goeschl <si...@it20one.at>]

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 <mi...@sharp.fm> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven vs. Scripted Build Systems

[Mykel Alvis <my...@weirdness.com>]

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 <mi...@sharp.fm> 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}
>

-- 
I'm just an unfrozen caveman software developer.  I don't understand your
strange, "modern" ways.

Re: Maven vs. Scripted Build Systems

[Graham Leggett <mi...@sharp.fm>]

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?

Scripted systems have an Achilles heel - build systems are not the primary
task at hand in a large project, the code is. As a result scripted build
systems are generally poorly designed and implemented, even though the
tools on which they are built (like ant) are top notch quality. The
scripted systems in every large project I've ever encountered were
complex, incomprehensible, platform specific and incomplete, and
ultimately thrown out.

The standardisation efforts of maven save a fortune - in our case on a big
project, releasing the project takes the form of "mvn release:prepare" and
"mvn release:perform", and that is it. This means that any member of a
project team can make a release, and that release will probably work first
time, or fail for very clear and obvious reasons.

> "how sustainable is maven for large scale projects"

Implementing maven is not a walk in the park in a complex project.

There are times when the classic maven design philosophy of "let maven
figure this out for you" doesn't always hold true, meaning you have to
understand enough about the build process to make sure things work
together.

Some of the maven plugins are not as reliable, or as complete than others.

But - having implemented a maven build system, all the maven features,
from release management, to documentation management, come for free. This
investment in standardisation pays big dividends in the future.

In short, the bigger the project, the more useful maven becomes.

Regards,
Graham
--



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven vs. Scripted Build Systems

[Arnaud Bailly <ab...@oqube.com>]

Hello,
I have been using maven for several years now, and switch from custom
grown ant scripts to maven1.0 in 200? (can't recall exactly the
year). The reason we switched is the usual one:
 - growing complexity and fragmentation of scripts 
 - uniformity and "industrialisation"
 - standard way of building, structuring and documenting projects.
 - reporting

This was true in maven1.X and is all the more so in maven2. 

I have set up maven on a project with +50 sub projects using custom
archetype: maven is great for industrializing development, when you
have a base project and several different modules that are built the
same. 

The profile system is extremely flexible and allows you to write in a
single place configurations for different environments
(eg. development, testing, production).  

The greatest feature, in my opinion, is the reporting system. It can
be somewhat tricky to put at work, but when properly configured, it
generates consistent information on your system, centralizes
documentation, project management info and quality reports. 

With continuum and (hopefully) archiva maturing, this makes for a
complete production system. 

There are drawbacks to maven's approach: lack of flexibility, tricky
configuration, centralized process, uniform way of building; and not
all plugins/components work as advertized but the list is responsive. 

My 50 cents


-- 
OQube < software engineering \ génie logiciel >
Arnaud Bailly, PhD

\web> http://www.oqube.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org