On Wed, Sep 07, 2005 at 04:54:04PM +0200, Milos Kleint wrote: > On 9/7/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > > 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. > > > fair enough. > > > 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 > > > ok. in my current understanding, the m1 plugins do actually use much more > properties than they declare. they use the pom, the common properties, then > their own props, even some undocumented one or other plugin's properties. > the m2's mojos make a better job at defining what they actually use. > you mentioned that reusing single mojo is ok without plexus. So chaining > multiple mojos is better done with plexus?
It depends on your use case, I'm imagining two major use cases:
1) Reusing a single Mojo as it has a smaller/easier/better/whatever API to
some other tool or functionality. Then you would instanciate the plugin
yourself, call the required setters and call execute().
2) You'd like to execute a whole build and then you should just embed
Maven as you're basically doing the same as we are in MavenCli.
I'm not entirely sure of what you are referring to when you'd like to
chain Mojos, but I suspect that it would fall under variant 2.
> > > 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.
>
>
> so by adding a new method to Mojo interface and implementing a default in
> AbstractMojo, you actually break all existing plugins. Unless they get
> recompiled against the current api. that's not a backward compatible way of
> evolving API contract. Abstract classes can add methods, to extend
> interfaces you need to create new version (either extending the original
> interface and making it independent), anything else breaks plugins.
>
> If Mojo were an abstract class rather than interface, it would help API
> evolution. (if that matters)
>
>
> <snip>
>
> > > 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?
>
>
> projecthelper+archiveconfiguration etc..
That is a valid point but it would not be really hard making a utility
that can wrap the invocation that's using Plexus to instanciate the
required components. Or you could just give it an implementation if you
are in a position to.
The Mojo annotations contains a special @component tag which is used to
indicate component/functionality requirements so they should be easier to
separate out once we've updated all the Mojos to use them.
> > 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.
>
>
>
> ok, now I'm confused again. Does that mean the docs for mojos are not the
> actual docs for the maven plugin? will there be 2 sets of documentation? one
> for mojo reusers and one for maven2 users?
Currently there's only the single page but you do have a good point that
the page layout definitely needs improvement. I'll make sure that the
component requirements and read-only parameters either gets moved to
another page or at least another section.
--
Trygve
signature.asc
Description: Digital signature
