maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Plugable/Softcoded/Customized Maven Plugins
Date Wed, 14 Jan 2015 14:15:25 GMT
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.rosenvold@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.rosenvold@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 <bimargulies@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message