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] > >
