<snip/>
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 http://wiki.codehaus.org/maven/HowToCreateYourFirstPlugIn2 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
