On Wed, Sep 07, 2005 at 10:11:40AM +0100, Ashley Williams wrote: > I was intrigued by a comment that we should avoid references to maven > in our home brewed plugins. I don't understand this, as if you write > a plugin for maven, then where else would it be used?? Maybe maven is > part of some bigger picture, but I only stumbled across the site in > search of a better Ant.
I guess my advice doesn't apply entirely in all cases, at least not the
cases where you are writing a plugin specific to a single build and cases
similar to that.
We try to make the core plugins as independent of Maven as possible (we
even try to put as many of the extensions on the Mojo project[1]) to
increase their reusability.
As for you question as to where Maven plugins can be resued, they can be
reused in your (possibly Maven like) code or in a IDE. Plugins like
checkstyle, javadoc and lots of others should be easily reusable.
> Anyway I took that advice as faith and attempted to remove reference,
> but a few still remain:
>
> 1. Mojo class inherits from AbstractMojo - of course
This is a integral part of the Mojo API as it will make it easier for us
to change/add stuff to the API without breaking plugins. And it also
implements the logging parts of the API.
As a side note you don't have extend the abstract class but as it's a part
of the maven-plugin-api artifact it doesn't add to your dependency list.
> 2. I did remove a reference to Project and instead included a Set
> reference:
> /**
> * @parameter expression="${project.artifacts}
> * @required
> */
> private Set projectArtifacts;
>
> BUT the set contained a list of Artifact objects which I have to cast
> into in order to get the path from each.
That is correct and in the process you lost a dependency on the
MavenProject object and maven-project artifact. From the re-users POV this
will be much easier to implement than giving an entire MavenProject
object. Constructing a mock MavenProject object is not an easy task which
is one of the resons why you should not depend on it.
> 3. Design: I'm happy to use the @parameter approach but just want to
> make sure this is correct. Because instead of having a nice concise
> Maven object to pass round OO style, I now have to explode these
> objects into a bunch of @parameters and end up creating methods as
> long as my arm.
The advantages of explicitly stating the parameters helps reuse and
improves the documentation of your plugin. Try this to get the
documentation for your plugin:
$ m2 plugin:xdoc site:site
(the plugin:xdoc is scheduled for a rewrite to a proper report soon)
But as I said if you don't care about reuse because you're only using this
internally, in a specific build or something like that there's nothing
wrong in just getting the MavenProject object and use that.
[1]: http://mojo.codehaus.org
--
Trygve
signature.asc
Description: Digital signature
