> -----Original Message-----
> From: Kristopher Brown
[mailto:[EMAIL PROTECTED]
> Sent: 13 May 2004 18:28
> To: Maven Developers List
> Subject: RE: Inter-plugin dependancy best practices
>
> Hi,
>
> Thanks for your swift response, however, I think the word "dependancy"
> possibly confused my point. I'm not talking about a plugin being
> dependant on another, more about how plugins affect shared variables.
This is fixed in RC3. You should use the <get>/<set> properties to
read/set other plugin properties.
> It's hard for me to explain it, that's why I used the example of
> maven.compile.src.set. Its about the modification of that variable
> rather than stated dependencies in the poms.
>
> Taking your explaination though, why isn't antlr plugin dependant on
> java plugin if in the jelly script it adds a pregoal to the
java:compile
> goal?
Probably for the reasons I've mentioned... :-) I would have done it
otherwise.
-Vincent
>
> in plugin.jelly:
>
> <preGoal name="java:compile">
> <j:if
test="${!antlrSrcDir.equals('MAVEN_ANTLR_SRC_DIR_NOT_SET')}">
> <attainGoal name="antlr:generate"/>
> </j:if>
> </preGoal>
>
> And also it modifies the variable to facilitate the java:compile goal
> compiling the generated source.
>
> <ant:path id="maven.antlr.compile.src.set"
> location="${maven.antlr.target.dir}"/>
>
> <maven:addPath id="maven.compile.src.set"
> refid="maven.antlr.compile.src.set"/>
>
> Hmm, if I'm not that clear I'll try to write a more thorough email
> later.
>
> Kris.
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: 13 May 2004 16:47
> > To: 'Maven Developers List'
> > Subject: RE: Inter-plugin dependancy best practices
> >
> > Hi Kristopher,
> >
> > > -----Original Message-----
> > > From: Kristopher Brown
> > [mailto:[EMAIL PROTECTED]
> > > Sent: 13 May 2004 17:18
> > > To: [EMAIL PROTECTED]
> > > Subject: Inter-plugin dependancy best practices
> > >
> > > Hi,
> > >
> > > How should plugin developers indicate that a plugin is
> > inter-dependant
> > > on anther plugin? Some have suggested a registering mechanism
like
> > that
> > > used by the site report. Another way is by modifying a shared
> > variable.
> > >
> >
> > There is already a mechanism in place. It's called
> > dependencies. Simply
> > add a dependency of type "plugin". For example:
> >
> > <dependency>
> > <groupId>xxx</groupId>
> > <artifactId>yyyy</artifactId>
> > <version>454354</version>
> > <type>plugin</type>
> > </dependency>
> >
> > It has the added advantage to automatically download the dependent
> > plugins if you don't have them in your local repository.
> >
> > The only issues I know are:
> > - you would usually like to say "use version > X.Y" instead of "use
> > version X.Y". If you say "use version X.Y" then you'll have
> > to remember
> > to upgrade the version every time the dependent plugin changes...
> > - if the user wants to use a given version of the dependent
> > plugin then
> > he cannot. A use case for that is for example if there is a bug in
the
> > version used then the user will want to use a previous version. I
got
> > this problem with the Cactus plugin which was depending on fixed
> > versions of the war and ear plugins and some users complained.
> >
> > [snip]
> >
> > Thanks
> > -Vincent
> >
> >
> >
---------------------------------------------------------------------
> > 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]
