Hmmm.  I'm leaving the original post in for reference, but if you don't mind
I'm going to play the devil's advocate for a second.  Don't get me wrong, I
like Maven, and I use it.

Some projects want to use Forrest.  There are a lot of features for Forrest
that are really nice--if you know how to use them.  There has been some work
to simplify the forrest integration, but it seems that Maven dist and deploy
want to use the Maven format for XDocs and its own document system.  There
is no support for integrating with the Forrest XDocs format, or having the
dist target use the Forrest plugin.

I imagine that certain things like that can be componentized so that when
we call the xdocs build targets, it deferrs either to the Maven or the Forrest
integration plugin.  That would be preferred.  However, how to do that seems
like a pipe dream with current Maven.  It's as if there needs to be a "document
plugin interface" of sorts.

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.

Conversely, with ANT, while it can be painful, it is obvious how to get things
done.

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 short, it is an
Artificial Intelligence phrase to describe the complex interactions between
agents that operate by very simple rules.  For example, research has shown that
a set of robots given a specific set of rules set loose in a room to collect
a specific set of blocks interact in surprising ways, even cooperating in
very complex ways to get the job done.

That's fine and dandy if we are trying to write a first person shooter game,
but for a build system we want a certain level of predictability.  I don't think
Maven has that--which is why we have posts like the one I listed here.

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.

Jason van Zyl wrote:

On Tue, 2003-09-30 at 09:08, Berin Loritsch wrote:

With ANT 1.6 on the horrizon, it appears that there are some new issues
to worry about.  For instance, the general impression that Maven is good
to you if you are good to Maven:

http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168

My question comes in this form:  How much difference is there between
a Maven 1.0 and the next generation Maven that fixes a bunch of the issues
we already have?

I mean, will the existing plugins work?


Yes. The current Maven will essentially be a component of its own. That
is not a problem. How well they will interact with new plugins I'm not
sure yet. But A lot of the standard plugins will more than likely just
be rewritten.


Is the repository compatible?


Yes, it will be. No plans to change the base structure.


If so, then I highly recommend the NG Maven sooner than later.


After 1.0 is released it will be a steam train toward the next version
and will be covered thoroughly in a book Bob and I hope to write. Bob
and I are meeting in Amsterdam this week to go over the outline and we
are going to keep users informed the whole way along which means getting
lots of input on the next version from users.


If not,
what can be done to make the plugins compatible?  What work needs to be
done in that respect?


Essentially the current version of Maven will work as a component.
Really it means making this version an encapsulated bean which I did
work toward and Brett is actually integrating that code. Once 1.0 is out
there will be a deluge of information and the book will be the initial
impetus and I hope the motivation to complete to end where the book
arrives around the release of the next version.



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



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



Reply via email to