I'd tend to agree - looks like this needs sorting throughout the plugin code base then :) there are quite a few occurances of it. Its usually the easiest way to get something working though, and is in keeping with the way that this has been achieved to date (not that this justifies it). I'd rather see the registering approach similar to that employed in the xdoc plugin (which would not have this antipattern).
> -----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]
