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" <[email protected]> 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 <[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 ! >
