So, I'm confused as to why asking people to add jars to the <dependencies/> of a <plugin/> is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold < [email protected]> wrote: > 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 < > [email protected]>: > > 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 <[email protected]>: > >> 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: [email protected] > For additional commands, e-mail: [email protected] > >
