On Wed, Jan 14, 2015 at 10:10 AM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote:
> It is only inconvenient because maven cannot resolve the artifact from > the current reactor, or at least it was not able to when I made > testcases for this for surefire-providers. > OK, now I'm with you. > > This means the extension has to be in a separate project and > built/deployed entirely separate module; this is an annoyance because > immediacy and user-accessibility is a key value in such stuff. I want > some of these extensions to be in my code base and to actually work > when I attach a debugger. Using modules deployed to central/some other > repo is also cool, but I really think we need to serve the "here and > now" case. > > So if I put the extension in my current project I will have to build > that extension specifically with mvn -N the first time, since it does > not exist somewhere it can be resolved. And I will always be using the > "previous" version when I build > > Kristian > > > > > 2015-01-14 15:15 GMT+01:00 Benson Margulies <bimargul...@gmail.com>: > > 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 < > > kristian.rosenv...@gmail.com> 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 < > >> 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >