Kostis,
Actually, despite the fact that I still think that creating the extra
goal is worthwhile from a usage standpoint, I agree that all of the
duplication is a bit silly. Unfortunately, I think that it's just a
design flaw in maven. Because the lifecycle seems to be nothing more
than descriptive labels to which plugin goals can be attached, there
is no mechanism for recognizing the similarity between, say,
generate-sources and generate-test-soucres. As a consequence, there's
bound to be duplication when you define lifecycle phases the way that
they did.
As Kohsuke mentioned, there are quite a few examples out there. Take
a look at, compile, resources and jxr to start.
Honestly, as much as I love Maven and recommend it to everyone, I'm
becoming less and less impressed with some of the underlying design
choices. Between the shortcomings in the lifecycle, the strange,
undocumented, proprietary frameworks that are only used in Maven (e.g.
plexus, modello, doxia) and some of the POM semantics, I find myself
wondering long it's going to be before somebody decides that Maven 3
is going to be a re-rewrite. Yeah, that's probably a bit
melodramatic, but nonetheless...
Anyway, the point was that regardless of the fact that it seems silly
to have to do it, I find it to be much less of a hassle to have an
extra goal than to have to create an extra project. Two classes one
time seems to be a better time investment than two poms every time I
need to test against jaxb-generated sources.
On 12/7/06, Kostis Anagnostopoulos <ankostis_at_gmail.com> wrote:
> On 12/7/06, Kostis Anagnostopoulos <ankostis_at_gmail.com> wrote:
> > Hi Kohsuke,
> >
> > On 12/7/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
> > > Gregory Kick wrote:
> > > > Hey guys,
> > > >
> > > > You're definitely on track with what I was thinking. The only other
> > > > plugin that I've ever seen implement something like this is the
> > > > xmlbeans plugin, which has a whole seperate goal for it. I think that
> > > > the flag makes more sense.
> > >
> > > Perhaps I'm too late, but the general practice for doing this is that
> > > the Maven plugin creates one Abstract Mojo that does most of the work,
> > > then derive two actual Mojos from there --- one for source and the other
> > > for test-source.
> >
> > The jaxb1 plugin is indeed structured like that: One abstract, that
> > does most of the job, and the actual mojo that provides the params,
> > logging, etc. Also, the hj2 plugin extends the abstract class.
> >
> > So technically, it is very easy to do it.
> >
> > But, i do question the need for such functionality.
> >
> > I'm not sure whether there will be a need also for separate test
> > dependencies, separate reports and javadocs, separate lifecycle. In
> > the end, we will start duplicating all pom functionality.
> >
> > That is why i think it is best to build the required test sources into
> > a jar using a separate pom, and included the result jar with
> > scope=test.
>
> I forgot Kohsuke to ask you which are these plugins that you remember
> applying the mentioned pattern (separate test sources mojo)?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
--
Gregory Kick
gk5885_at_gmail.com