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

Reply via email to