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
>
>
