OK thanks. So are you saying that if I just delete the 'extends
AbstractMojo' then the plugin will still work (maybe by reflection or
codegen)?
Glad I've got your attention because I'm having a few problems with
the source:jar goal (saw your name on it!). I've placed my pom at the
same level as my java source and m2 install works fine:
com/acme/proj/ [MyMojo.java, pom.xml]
However when I run the source:jar goal and inspect the jar, the
MyMojo.java class is at the top level. Obviously if I hadn't made m2
install work then I would have expected this but I believe I've made
the necessary pom adjustments:
<build>
<sourceDirectory>.</sourceDirectory>
Actually I can sort of imagine why source:jar would have trouble with
this because I can't see in the pom anywhere where you can enter a
package name for the plugin to work out how many directories to go
'up' before doing the jar. Anything I can do locally on my machine?
On 7 Sep 2005, at 11:39, Trygve Laugstøl wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
