Without some kind of defined (and widely used!) mechanism for
source-modifying plugins to do their thing, it's not clear how they have any
real choice in the matter.  Does there exist a better way that works right
now?

> -----Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 19 May 2004 11:15
> To: 'Maven Users List'
> Subject: RE: Xdoclet & Eclipse
> 
> 
> <slightly OT>
> 
> My view is that it's a bad practice (anti-pattern) for a plugin to use
> preGoal/postGoal. Plugins should provide their own goals, possibly
> wrapping existing goals.
> 
> </slightly OT>
> 
> -Vincent
> > -----Original Message-----
> > From: Kristopher Brown
> [mailto:[EMAIL PROTECTED]
> > Sent: 19 May 2004 12:06
> > To: Maven Users List
> > Subject: RE: Xdoclet & Eclipse
> > 
> > You can't easily.  It's a general problem with plugins that "affect"
> the
> > compile set, i.e. generation plugins such as antlr, castor etc, and
> > plugins that should "utilise" the compile set, e.g. java:compile,
> > javadoc, and ide plugins.
> > 
> > Personally I think it should all be addressed in the same way across
> all
> > the plugins of this nature - there are a few variations and 
> different
> > people have done it different ways.  At the moment, most generation
> > plugins include a preGoal for java:compile in plugin.jelly to ensure
> > they are called before the compile occurs.  java:compile is just one
> > goal that requires the generation goals to have occurred 
> (or at least
> > the part that adds the generation path to the src set), and people
> have
> > solved their plugin for this case as its typically the most used.
> > 
> > javadoc, eclipse et al. need this modification to src.set to have
> > occurred for them too.  One easy way to ensure that this 
> has occurred
> is
> > to perform java:compile as a preGoal to the goal you are using
> > eclipse/javadoc.  This does more work then is needed, but it would
> > ensure that any generation modification have occured.  Another way
> would
> > be for the affecting plugins to be aware of all projects 
> that utilise
> > the src.set and add a preGoal to them, but this would get 
> bloated very
> > quickly.
> > 
> > There seems to be something missing in all of this though, a way in
> > which a plugin can say that is a "src.set affecting" plugin 
> and a way
> in
> > which a plugin can say it's a "src.set utilising" plugin.  Then all
> the
> > utilising projects would have to do is iterate down the list of
> > affecting plugins and call their src.set modifying goal, 
> then do what
> > they need.  I think this is similar to the way in which the reports
> work
> > for site generation, i.e. they register themselves, and site calls
> them
> > back as and when needed.  This would be a fairly huge 
> undertaking for
> > someone to sort out though.
> > 
> > So for the eclipse plugin to work in the short term:
> > 1. it needs to utilise the maven.compile.src.set rather than
> > pom.build.sourceDirectory - this is a similar issue to what people
> have
> > been discussing re the javadoc plugin.
> > 2. the plugins need to interact somewhat to ensure that the src set
> has
> > been populated with the generated src.set.  This can be 
> done by adding
> a
> > custom preGoal in you maven.xml file for eclipse to call 
> java:compile,
> > or you could isolate the src.set affecting goal in xdoclet and call
> that
> > goal instead.
> > 
> > Kris.
> > 
> > > -----Original Message-----
> > > From: LOMBART Christophe
> > > [mailto:[EMAIL PROTECTED]
> > > Sent: 19 May 2004 10:34
> > > To: [EMAIL PROTECTED]
> > > Subject: Xdoclet & Eclipse
> > >
> > > Hi All,
> > >
> > > I'm using Maven + eclipse + xdoclet.
> > >
> > > When I run "maven eclipse", I want to add in the eclipse
> > > project source folder list the location of xdoclet generated
> > > files (/target/xdoclet/ejbdoclet).
> > >
> > > How I can do that ?
> > >
> > >
> > > Kind regards,
> > > Christophe
> > >
> > >
> ---------------------------------------------------------------------
> > > 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]
> 
> 
> 
> ---------------------------------------------------------------------
> 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