+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 <[email protected]>
> 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
