You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2013/04/09 13:06:56 UTC
User defined plugin extension points ?
surefire (and quite a few other plugins) seem to be screaming for a
simple way to add user-defined extension points for easy ability to
modify/extend capabilities without forking the plugin or further
bloating it for yet more marginal use cases.
Conceptually I'm thinking somewhere along these lines:
make plugin export an "extension-api" jar with interfaces. Anyone can
implement one or more of these interfaces and put them on the plugin's
dependency classpath. Using something like the SPI api, the plugin
picks up and executes this user code at the appropriate places.
(Alternately the implementation could also export the impl's as plexus
components and use DI injection instead - unsure if that'd work...?).
I am a bit surprised we're not doing anything like this ? Is there a
different approach that'd be better ? (I'd love a wicket-style
approach ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: User defined plugin extension points ?
Posted by Robert Scholte <rf...@apache.org>.
If this would help with MRELEASE-564 and other equivalent issues I'm all
ears.
The issue I'm facing is that the maven-release-plugin can't detect
dependencies/artifacts specified within the configuration. These are files
you can't just add to the dependencies of the plugin, because they have a
special purpose. The maven-javadoc-plugin is probably the best example of
sets of different artifacts with different purposes:
additionalDependencies, bootclasspathArtifacts, docletArtifacts,
resourcesArtifacts, tagletArtifacts.
This should work for previous versions of Maven as well, so it should
somehow become part of plugin-tools.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-564
Op Tue, 09 Apr 2013 21:52:16 +0200 schreef Romain Manni-Bucau
<rm...@gmail.com>:
> Doesnt each plugin needs its own handling?
>
> Maybe some event base siluyion with just a spi yo register listeners is
> better (like in arquillian)
> Le 9 avr. 2013 21:49, "Baptiste MATHUS" <bm...@batmat.net> a écrit :
>
>> +1. Would be great.
>> I was recently thinking about this when designing an enforcer rule about
>> naming & dependency rule. I want to define some simple config through
>> XML,
>> but also considered being able to inject some kind of
>> DependencyNamingRulesStrategy by anyone who would not have enough with
>> the
>> standard behaviour.
>>
>> Btw, isn't it actually what menforcer is currently doing (with some
>> specific way and simplified for the "end-user" to write rules, sure)?
>>
>> Cheers
>>
>>
>> 2013/4/9 Andreas Gudian <an...@gmail.com>
>>
>> > How does the wicket-style approach look like?
>> >
>> > I think we should end up with something that allows to have:
>> > * multiple implementations of the same interface, e.g. different test
>> > filters, different test run listeners
>> > * configurable extensions, e.g. configure details for the filters or
>> run
>> > listeners directly in the pom.xml.
>> >
>> > Something like SPI would be great on the first point, but I don't yet
>> have
>> > a clue on the configuration part.
>> > Hm, perhaps by adding a somewhat generic configuration in form of a
>> map
>> > (like with systemPropertyVariables) and pass it to each SPI-resolved
>> > implementation before actually using it. Then the implementors can
>> > configure their extension based on such simple key/value mappings.
>> >
>> > Andreas
>> >
>> > Am Dienstag, 9. April 2013 schrieb Kristian Rosenvold :
>> >
>> > > surefire (and quite a few other plugins) seem to be screaming for a
>> > > simple way to add user-defined extension points for easy ability to
>> > > modify/extend capabilities without forking the plugin or further
>> > > bloating it for yet more marginal use cases.
>> > >
>> > > Conceptually I'm thinking somewhere along these lines:
>> > >
>> > > make plugin export an "extension-api" jar with interfaces. Anyone
>> can
>> > > implement one or more of these interfaces and put them on the
>> plugin's
>> > > dependency classpath. Using something like the SPI api, the plugin
>> > > picks up and executes this user code at the appropriate places.
>> > >
>> > > (Alternately the implementation could also export the impl's as
>> plexus
>> > > components and use DI injection instead - unsure if that'd
>> work...?).
>> > >
>> > > I am a bit surprised we're not doing anything like this ? Is there a
>> > > different approach that'd be better ? (I'd love a wicket-style
>> > > approach ;)
>> > >
>> > > Kristian
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: User defined plugin extension points ?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Doesnt each plugin needs its own handling?
Maybe some event base siluyion with just a spi yo register listeners is
better (like in arquillian)
Le 9 avr. 2013 21:49, "Baptiste MATHUS" <bm...@batmat.net> a écrit :
> +1. Would be great.
> I was recently thinking about this when designing an enforcer rule about
> naming & dependency rule. I want to define some simple config through XML,
> but also considered being able to inject some kind of
> DependencyNamingRulesStrategy by anyone who would not have enough with the
> standard behaviour.
>
> Btw, isn't it actually what menforcer is currently doing (with some
> specific way and simplified for the "end-user" to write rules, sure)?
>
> Cheers
>
>
> 2013/4/9 Andreas Gudian <an...@gmail.com>
>
> > How does the wicket-style approach look like?
> >
> > I think we should end up with something that allows to have:
> > * multiple implementations of the same interface, e.g. different test
> > filters, different test run listeners
> > * configurable extensions, e.g. configure details for the filters or run
> > listeners directly in the pom.xml.
> >
> > Something like SPI would be great on the first point, but I don't yet
> have
> > a clue on the configuration part.
> > Hm, perhaps by adding a somewhat generic configuration in form of a map
> > (like with systemPropertyVariables) and pass it to each SPI-resolved
> > implementation before actually using it. Then the implementors can
> > configure their extension based on such simple key/value mappings.
> >
> > Andreas
> >
> > Am Dienstag, 9. April 2013 schrieb Kristian Rosenvold :
> >
> > > surefire (and quite a few other plugins) seem to be screaming for a
> > > simple way to add user-defined extension points for easy ability to
> > > modify/extend capabilities without forking the plugin or further
> > > bloating it for yet more marginal use cases.
> > >
> > > Conceptually I'm thinking somewhere along these lines:
> > >
> > > make plugin export an "extension-api" jar with interfaces. Anyone can
> > > implement one or more of these interfaces and put them on the plugin's
> > > dependency classpath. Using something like the SPI api, the plugin
> > > picks up and executes this user code at the appropriate places.
> > >
> > > (Alternately the implementation could also export the impl's as plexus
> > > components and use DI injection instead - unsure if that'd work...?).
> > >
> > > I am a bit surprised we're not doing anything like this ? Is there a
> > > different approach that'd be better ? (I'd love a wicket-style
> > > approach ;)
> > >
> > > Kristian
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
Re: User defined plugin extension points ?
Posted by Baptiste MATHUS <bm...@batmat.net>.
+1. Would be great.
I was recently thinking about this when designing an enforcer rule about
naming & dependency rule. I want to define some simple config through XML,
but also considered being able to inject some kind of
DependencyNamingRulesStrategy by anyone who would not have enough with the
standard behaviour.
Btw, isn't it actually what menforcer is currently doing (with some
specific way and simplified for the "end-user" to write rules, sure)?
Cheers
2013/4/9 Andreas Gudian <an...@gmail.com>
> How does the wicket-style approach look like?
>
> I think we should end up with something that allows to have:
> * multiple implementations of the same interface, e.g. different test
> filters, different test run listeners
> * configurable extensions, e.g. configure details for the filters or run
> listeners directly in the pom.xml.
>
> Something like SPI would be great on the first point, but I don't yet have
> a clue on the configuration part.
> Hm, perhaps by adding a somewhat generic configuration in form of a map
> (like with systemPropertyVariables) and pass it to each SPI-resolved
> implementation before actually using it. Then the implementors can
> configure their extension based on such simple key/value mappings.
>
> Andreas
>
> Am Dienstag, 9. April 2013 schrieb Kristian Rosenvold :
>
> > surefire (and quite a few other plugins) seem to be screaming for a
> > simple way to add user-defined extension points for easy ability to
> > modify/extend capabilities without forking the plugin or further
> > bloating it for yet more marginal use cases.
> >
> > Conceptually I'm thinking somewhere along these lines:
> >
> > make plugin export an "extension-api" jar with interfaces. Anyone can
> > implement one or more of these interfaces and put them on the plugin's
> > dependency classpath. Using something like the SPI api, the plugin
> > picks up and executes this user code at the appropriate places.
> >
> > (Alternately the implementation could also export the impl's as plexus
> > components and use DI injection instead - unsure if that'd work...?).
> >
> > I am a bit surprised we're not doing anything like this ? Is there a
> > different approach that'd be better ? (I'd love a wicket-style
> > approach ;)
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: User defined plugin extension points ?
Posted by Andreas Gudian <an...@gmail.com>.
How does the wicket-style approach look like?
I think we should end up with something that allows to have:
* multiple implementations of the same interface, e.g. different test
filters, different test run listeners
* configurable extensions, e.g. configure details for the filters or run
listeners directly in the pom.xml.
Something like SPI would be great on the first point, but I don't yet have
a clue on the configuration part.
Hm, perhaps by adding a somewhat generic configuration in form of a map
(like with systemPropertyVariables) and pass it to each SPI-resolved
implementation before actually using it. Then the implementors can
configure their extension based on such simple key/value mappings.
Andreas
Am Dienstag, 9. April 2013 schrieb Kristian Rosenvold :
> surefire (and quite a few other plugins) seem to be screaming for a
> simple way to add user-defined extension points for easy ability to
> modify/extend capabilities without forking the plugin or further
> bloating it for yet more marginal use cases.
>
> Conceptually I'm thinking somewhere along these lines:
>
> make plugin export an "extension-api" jar with interfaces. Anyone can
> implement one or more of these interfaces and put them on the plugin's
> dependency classpath. Using something like the SPI api, the plugin
> picks up and executes this user code at the appropriate places.
>
> (Alternately the implementation could also export the impl's as plexus
> components and use DI injection instead - unsure if that'd work...?).
>
> I am a bit surprised we're not doing anything like this ? Is there a
> different approach that'd be better ? (I'd love a wicket-style
> approach ;)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>