Your Centipede sounds like a fun project to work on. I forgot by now the point you are trying to make. While there are differences in how Maven and Centipede do things, in the end we strive for the same goal I guess. Make the end user happier and more productive. We have each made our choices. Trying two different approaches will help weed out the bad design.
You are good at pointing out differences in implementation, but I have not heard anything concrete that one product can do and the other can't. Before writing one or the other off, I'll wait a while and see what the end user has to say. In a year, lets compare Maven and Centipede and have this conversation again. It would be interesting. -Peter ----- Original Message ----- From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> To: "Vincent Massol" <[EMAIL PROTECTED]> Cc: "'Turbine Maven Users List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, July 04, 2002 9:17 AM Subject: Re: [Centipede] Final proposal > > Vincent Massol wrote: > > Hi Nicola, > > > > [snip] > > > > Trying to have each plugin independent one of another is a nice goal. > > But difficult to achieve without lots of build code duplication. Just > > check the Ant dependency graphs > > (http://www.teria.com/~koseki/vizant/examples.html), you'll see that > > there are dependencies between functional build units. If you normalize > > them, you duplicate lots of code. > > I don't normalize them. I simply don't rely on them. > > > Thus, we need a way to tell the master build that before we run our new > > plugin, it has to run such and such targets/goals from such other > > plugin. Yes, I know, we introduce plugin dependency but just as long as > > our new plugin only relies on core plugins there is no problem (same > > issue as Ant build files relying on core ant tasks vs optional ones - we > > just abstract one level higher, plugins instead of tasks). > > I go one level higher again. > I define features, which are collections of tasks that attain a logical > goal (compile, test, etc...) > > > In addition, let's say I add a Test Coverage plugin. As a user, I may or > > may not want it to be called when I run the "site" target to generate > > the web site. Thus I need a way to tell this to Maven. > > > > Maven provides a default wiring of targets but we need to let the user > > the ability to add either his own build code before/after or change the > > order of targets (not sure we have that yet in Maven, do we Jason/Bob ? > > I mean can a user change the default sequence order of targets ?). > > > > I don't see what is wrong with that ? > > Not wrong, just unnededly convoluted. > > Look, you overload the concept of target by giving it a logical goal: > build, site, jar, etc. > Then give it a default implementation, a default dependency and pre and > post additional stuff. > > What we do is instead to define features (your common goals), define the > dependency between them, but don't define either the default > implementation nor pre or post stuff. > We just put a sequence of plugin goals there. > > It's just a different way of doing the same thing; we reckon it's easier > to maintain, understand and create. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
