On Wed, Sep 07, 2005 at 01:41:13PM +0200, Milos Kleint wrote: > 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?
If they already have a existing useful API use it, if they don't and
there's a Mojo for it you can use the Mojo. Also note that if what the
Mojo do is sufficient for what you're trying to do it's not unlikely that
the Mojo's API will be any harder to use as it's bound to have
documentation and as a consumer you'll only have to use a single Java
class.
> 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?
These two points are definitely related, see [1] for the status on
setter-based support. To reuse a single Mojo you will not have to use
Plexus at all, the only thing you need is a ClassLoader with all the
dependencies of the Mojo.
It is our intention to make the Mojos reusable outside Maven
> 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?
Why am I wrong in that removing dependencies make them *more* reusable?
Lots of the Mojos are just smaller snippets, the smaller the better. You
don't have to use the code just because it's there. The documentation is
admittedly completly filled out yet but will be one of the main focues
after the first beta release.
> > 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?
This was not really a good example, it was more of a general reference as
to now you can use abstract classes to make it easier to change APIs over
time.
I do not think that we will change the Mojo API in the nearest future but
if we do we will only add stuff. Now this is where extending a abstract
class is useful because it could have a default implementation or whatnot.
> > 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)
Yes, as with all code you're expected to read the documentation, I don't
see the big deal. We will document both the Mojo API and the individual
Mojos better before the final release.
> 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.
Sort of, but again better docs would help out here.
> -> the only advantage is limiting the scope, knowing what is actually used
> by the mojo. am i correct?
That is not the only advantage here but it's definitely one of them. It
will prevent you from having to construct and configure the entire
MavenProject object (which is a very big object).
> then again, i'm exposing the inner workings and contracts of the plugin to
> the plugin user.
What parts are you referring to?
> 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?
You can't change that as a Maven 2 user (using the m2 command) but as a
Mojo consumer you will have to set it.
[1]: http://jira.codehaus.org/browse/MNG-626
--
Trygve
signature.asc
Description: Digital signature
