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