User extensions could be used for something like logging maybe and that would be fine. User extensions that may knock out project extensions that are required to build are is an issue. A user installs a extension to colour the log output, so what. But the first binding discovered is what works, that how our extensions work, so if we just allowed them to be loaded without any validation it can certainly cause issues if user extensions were to have priority. We currently don’t have any notion of scoping how an extension is used. We might not want to allow the smart builder, for example, to be use on any project from a user configuration as it simply may not work. Just loading the extensions would now be easy because the mechanism is in place but I don’t think that’s enough.
> On Jan 12, 2016, at 1:19 AM, Tamás Cservenák <[email protected]> wrote: > > +0 in general, but I think we should first check how multiple extensions > will/may work, and see, what actually, was the original intention of > extensions. We might miss some important reasons to NOT do this (maybe due > to some technical reason?) > > For example, I use Takari smart builder, Takari concurrent local repo and > okhttp connector. > For now, if I put these on "installation" level, but I may have some other > connector on "user" level, while some project I checked out may define it's > own in .mvn... can we guarantee that Maven will keep working correctly? > > I am targeting at fact that extension loading is not verified in same way > as plugins are, they are "just" sisu components, and they may cause havoc > by replacing -- or the opposite -- by non replacing things due to > priorities on other level extensions.... > > Well, we could assign priorities to extension sources (distro, user, > project, like latter overrides former), but given that SISU @Priority is > already used to select some components, this is a bit... hm, convoluted? > > Now that I think about it, this becomes not quite trivial thing to resolve > properly :D > > > > On Tue, Jan 12, 2016 at 9:12 AM Stephen Connolly < > [email protected]> wrote: > >> +1 >> >> On Tuesday 12 January 2016, Hervé BOUTEMY <[email protected]> wrote: >> >>> installation level need to point to user space, in a per-user location >> (~, >>> or >>> ${user.home} if you prefer this syntax): then the user space is filled or >>> not, >>> user per user >>> >>> multi-user installation is exactly the target use: with this user >>> extensions >>> feature, each user can customize its own extensions without doing a full >>> Maven >>> installation >>> >>> Regards, >>> >>> Hervé >>> >>> Le mardi 12 janvier 2016 08:14:28 Anders Hammar a écrit : >>>>> Then I think we are missing *user* extensions, that would be added in >>>>> ${maven.home}/bin/m2.conf the same way as installation extensions, >> but >>>>> pointing to ~/.m2/ext/*.jar >>>> >>>> What would the benefit be of configuring this on installation level but >>>> keep the jar in user space? How would that work for a multiuser >>>> installation? >>>> >>>> /Anders >>>> >>>>> This would give us 3 levels of extensions: >>>>> - installation: as available for ages >>>>> - user: could be configured manualy on old Maven installation, and >>> would >>>>> be >>>>> available with Maven 3.4.0 distribution >>>>> - project: as added in Maven 3.3.0 >>>>> >>>>> Any objection? >>>>> I still didn't create corresponding Jira issue, but will do if >>> popsitive >>>>> feedback >>>>> >>>>> Regards, >>>>> >>>>> Hervé >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>> <javascript:;> >>>>> For additional commands, e-mail: [email protected] >>> <javascript:;> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] <javascript:;> >>> For additional commands, e-mail: [email protected] >> <javascript:;> >>> >>> >> >> -- >> Sent from my phone >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- {script:nopre:"/Users/jvanzyl/signature/signature.sh"} --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
