maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: More constructive criticism
Date Tue, 30 Sep 2003 15:18:56 GMT wrote:


>> Also, getting started--esp. if you have several smaller projects that make up
>> one larger project is not very easy.  For instance I have my GUIApp project
>> using Maven.  It works great, and the reactor (once I got it working)does its
>> job.  Unfortunately, getting the parent project to create a distribution with
>> the proper documentation and packaging isn't set up.  I'm somewhat at a loss
>> how to do this.
> Have you looked at how Maven produces it's installation/distribution?

:) Remember, I am playing devil's advocate here.  I will look at it, but the
point is that I *shouldn't* have to.

>> Conversely, with ANT, while it can be painful, it is obvious how to get things
>> done.
> It's also DEAD easy to write Maven plugins.

My experience is a bit different in this matter.  The chief accomplice to this
issue is the lack of any meaningful documentation on Jelly.  You sort of have to
"discover" how it is used and what is legal syntax.

The thing is that with the pre/post goal operations, I can easily enhance
existing behavior, but certain things required me to change an existing
plugin--which should be happily part of the Maven RC1 by now.  Remember that it
depends on *what* you want to do. Easy things are easy, but hard things are
seemingly impossible.

In fact, the pre/post goal thing is part of the reason for the emergent
behavior that I described.  You see, if I call guiapp:install-snapshot,
the JARs created with my GUIApp plugin will have the meta-info I wanted.
If I call the jar:install-snapshot, I won't get the meta-info I wanted,
even though I provide a <preGoal name="jar:install-snapshot"/> entry.

It took me a while to figure this out.  Also, how do you keep certain
plugins from interacting with the build if you don't want them to?  I imagine
that eventually we will have some plugins that conflict with one another.

>> I think the best thing that describes developing a Maven plugin, and trying to
>> make it work the way you want it to is "emergent behavior".  In
> [snip]
> You mean something like 
> is "emergent
> behaviour"? You and I have very different opinions on that one.

How many plugins are that braindead?  Any plugin that defines pre/post
goals that modify the behavior of an installed plugin in some way classifies
as emergent behavior.  It's not a dig, but it is reality.

>> As it is, Maven is very usable, and I like it alot.  I also think it can be
>> improved to provide some level of predictability.
> Speak to me in words I can use to create issues :-)


Some of it comes from the need for strategy docs.  The simple case is
documented, but what about the more complex sub-project style projects?
There is little to help in that regard.  Some of it comes from using a
scripting language that has no meaningful documentation so unless you have
been initiated you are in the dark.

Other issues come from the loose pre/post goal type of issues.  Its a hard
balance to walk.  On one hand a rigid definition of build stages will help
to provide standard interfaces for making parts of the build happen in very
predictable manners.  On the other hand, defining that rigid set of
interfaces is not easy, and doesn't allow for some truly flexible solutions
we can do now.  I really have no advice on this.  All I can do is play
devil's advocate, or explain the points of difficulty I have had.

To be fair, this community has been very helpful to me, and it is home to
a group of top notch folks.  It's alot easier to manage my projects with
Maven than plain ANT, and have a level of consistency with it.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message