> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> Sent: 04 July 2002 17:08
> To: Turbine Maven Users List
> Subject: Re: [Centipede] Final proposal
>
>
> James Strachan wrote:
> > From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>>We use composition, you use inheritance.
> >>>
> >>>We both use composition.
> >>
> >>Composition means that you take things and put them together.
> >>Inheritance means that you extend available stuff.
> >>
> >>Maven plugins are customization, that is extensions of the common
Mavan
> >>build, that is basically inheritance.
> >>
> >>In Java, super() is basically a pre-callback...
> >>
> >>Is this correct?
> >
> > Kinda yes.
> >
> >>What is the real value of callbacks?
> >
> > Think end user for a moment. I might work on 10 or so projects that
all
> > pretty much use the same tasks/cents/plugins. Lets say javac, jar,
> javadoc,
> > junit. Though I end up having to maintain a build.xml for each of
these
> > projects that essentially does the same thing; sure its reusing the
same
> > tasks/cents/plugins but its a PITA to maintain the build.xml
documents.
> Then
> > add auto-downloading of dependencies and classpath issues to the
mix.
> >
> > Now with Maven we can all share a standard build system that can
fully
> build
> > all of these 10 projects out of the box. No build.xml to maintain or
> > classpath to set etc. Now if one of the builds wants to add some
funky
> code
> > generation, or some special document-generation step, we can use
> 'callbacks'
> > (which is the old term when we used Ant-call backs) to customize the
> build
> > process without having to cut'n'paste'n'maintain the same Ant stuff
for
> > other bits like javac, javadoc, junit, jar, binary distros etc.
>
> Look, it seems you haven't understood Ant.
> You can import common build snippets with entities and use them as-is,
> (with no modification) or use them via <antcall> (not <ant> ;-) in
your
> specific targets; all with the order you prefer, not having to make
> pre-post, etc.
>
> Entities though are not the best solution, so I made the import tag
that
> does the same thing, only in a more elegant matter.
>
Look. I think we are talking about the same thing. Except that in Maven
case there is no need for a build.xml file at all. However, it is
certainly needed for more complex builds (which is the reason for our
maven.xml). In addition, Jelly let's us access easily the XML POM.
[snip]
-Vincent
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
