On 9/7/05, Trygve Laugstøl <[EMAIL PROTECTED]> 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.
sorry, i'm not buying this.
1. could you give an example on what would the IDE or my custom code use
this for? and especially why I should I use it instead of plainly using
checkstyle/pmd apis?
2. what is the whole plexus container's role when executing the mojo? will I
have to drag it with me when trying to run the mojos? many of the parameters
are either expressions or assume some default values that is constructed by
the container (my guess so far, correct me if I'm wrong). So any less than
trivial plugin will have heaps of such parameters. and most of the "magic"
setting them up happens behind the scenes, done by the container.
3. maybe unrelated and stupid question: are all these paremeters settable by
m2 plugin user? or how does one differentiate the user level parameters from
all those params which are more or less just a mojo x container x maven
contract?
4. rant: if you think just making the code independant of maven makes it
reusable, then you are wrong. so far the mojos I browsed are just very
simple code snippets, without documentation (!), but with parameters that
are being set somewhere in the midair by some magic. how reusable is that?
> 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.
hmm.. one can extend the abstractmojo class which allows you to change APIs
backward compatibly? abstract classes are more maintainable than
interfaces.. good.
BUT.. then those who don't extend the abstract class become 2nd class
citizens because the additional apis/features will not apply to them. or
what is the design strategy there?
> 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.
as a re-user I still have to
1. check all the comment tags and understand them (eg @required has to be
set)
2. i have to know what project.artifacts expressing resolves to, meaning
what kind of objects are expected there. So I still have to examine, use and
depend on the maven-project artifact in my code.
-> the only advantage is limiting the scope, knowing what is actually used
by the mojo. am i correct?
then again, i'm exposing the inner workings and contracts of the plugin to
the plugin user.
I've tried generating docs for maven-ejb-plugin as an example:
there's like 7 properties of which 4 look like the plugin's guts (contract
to container/maven) rather than something that makes sense to set by the
user. or how does it help me to know that I can set MavenProject instance?
or MavenProjectHelper? or MavenArchiveConfiguration?
or in the case discussed above the list of Artifacts? Would I ever want to
change that as maven 2 user?
Milos Kleint
