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
