If we additionaly look for a solution that would work straight out of the box for maven 3.0, the plugin could actually just use some kind of loader library that would load/detect the supplied artifact into the plugin classloader and use lazy container lookup logic when resolving the user-supplied service. In that way you'd end up with something like this:
DiscoveryService.findExtensions(); // Do something magic which loads jar in plugin classloader RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class); if (userSupplied != null) { // Use usersupplied } Now all we'd have to do was put RunOrderSorter in a "client-api" module, and we could load it at will. We just need an implementation for the "Do something magic" bit above.... This 2015-01-14 13:43 GMT+01:00 Kristian Rosenvold <kristian.rosenv...@gmail.com>: > Agreed Benson; I find it very interesting to reduce this problem > initially, then we can grow it afterwards once we sort of understand > what it would take. > > We could very well use standard DI to "export" the service-overrides > from our custom expansions module. plexus annotations should do quite > nicely. This would leave us with "how does this get injected" problem. > As I mentioned, I don't think dependencies within the plugin section > work straight our of the box. > > It would probably be *simplest* to require single-module per extension > since you could then avoid polluting plugin classloaders with stuff > from the "wrong" plugin. from a users perspective it might make a lot > of sense to put something like "maven-assembly-plugin-client-api" and > "surefire-client-api" as s dependency to a single module called > "maven-extensions", but then we'd be loading surefire-client-api and > other deps into the maven-assembly-plugin classloader; which sounds > like a very bad idea. > > So if we stick with 1:1 extension<->plugin, all we'd need is some way > to pick up the impl... > > K > > > 2015-01-14 13:18 GMT+01:00 Benson Margulies <bimargul...@gmail.com>: >> yes, let's please decouple 'how do we get more code into the classspath' >> from 'how to we tell a plugin to use the code.' >> >> For the first, we have the plugin's dependencies. >> >> For the second, well, don't we have plexus component injection? Obviously, >> there are more modern alternatives, but shouldn't we bite that bullet >> globally if we are going to bite it at all? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org