On 6 April 2010 08:46, Jörg Schaible <joerg.schai...@gmx.de> wrote:

> Wayne Fay wrote at Montag, 5. April 2010 22:54:
>
> >> could you please elaborate a bit on these "few reasons"?
> >
> > Stolen from an email by Jorg Schaible in Nov 2009...
> >
> > In short: Don't do it, it is not supported by the Maven classloader.
> >
> > Long version: Maven loads every plugin/Mojo only once either because it
> is
> > used in the POM by the user or because some malicious plugin loads it as
> > dependency. Now, if the user and the malicious plugin do not agree over
> > the plugin's version and the plugin versions are no longer compatible,
> the
> > build simply breaks.
>
> Just as an additional comment: AFAICS this is gonna be addressed in 3.x,
> but
> I don't know the current state of it. Therefore, I'd stay for the time
> being
> without deps to plugins :)
>

AFAIK the fully solution also requires plugins to be annotated with Java5
annotations.

There are two issues with re-use of plugins:

   - The classloader issue (AFAIK this is resolved in 3.0-alpha-X where X is
   at least <= 06)
   - The plugin.xml metadata - basically m-plugin-p processes the javadoc
   comments in order to determine what the configuration of a mojo is.  Since
   the source code (and hence the javadocs) is not available for a dependency
   (when m-plugin-p runs) you cannot extend a mojo from a different plugin.
   IIRC, the solution to this problem is to annotate using Java5 Annotations as
   these will be retained in the class files.

   That does raise the issue that once annotations are used, you will only
   be able to extend plugins which are annotated with Java 5 annotations.

   I suspect that this could also be solved if m-plugin-p parsed the
   plugin.xml files from the classpath... but AFAIK that has not been done
   yet.  I might look into the same myself just to aid consolidating
   m-surefire-p and m-fairsafe-p

-Stephen


> >> resolve its dependency on the xml-maven-plugin. I can't see the
> >> difference between depending on a plugin artifact and depending on a jar
> >> artifact.
> >
> > There is a great difference for reasons internal to Maven.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to