maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@takari.io>
Subject Re: Why are extensions project based and not global?
Date Thu, 28 May 2015 16:57:36 GMT
I think some of the more complex use cases we've worked through: like the Ruby DSL for JRuby
and Aether connectors. Both those work and Igor is working through one of the tricky ones
now which is logging. I've seen a few extensions in the wild too so hopefully there isn't
going to be much we find. But yes, extensions need to be used more.

On May 28, 2015, at 12:35 PM, Manfred Moser <manfred@mosabuam.com> wrote:

> True ... with great power comes.... 
> 
> But to lighten that we could by default say that project based extensions override global
ones.
> 
> Realistically I think we just have to use it all more and get more practical experience
with extensions to see where we might want to head next.
> 
> Manfred
> 
> Jason van Zyl wrote on 28.05.2015 09:21:
> 
>> The downside here is that what you might have configured locally, personally,
>> may conflict with what a project might have setup.
>> 
>> At the project level it's safe, organizationally it can be if curated but a
>> personal setup working with something not explicitly configured for a specific
>> project is asking for support problems.
>> 
>> On May 28, 2015, at 11:58 AM, Manfred Moser <manfred@mosabuam.com> wrote:
>> 
>>> I think having a global config for this would be good. Personally I think
>>> having .m2/extensions.xml would be a good way to do it.
>>> 
>>> You could introduce e.g. Igor's logging here, add the Takari concurrent local
>>> repo access and so on in a declarative fashion and truly customize your Maven
>>> installation. Installation rather than project usage! 
>>> 
>>> And it would be fine to switch between Maven installations and it would also
>>> be applicable e.g. to an embedded Maven in M2e or another tool.
>>> 
>>> The loading problem of e.g. starting the groovy extension on each project
>>> exists but that comes down to carefully choosing which extensions you always
>>> want and which ones you have project specific. And we can maybe look at each
>>> extension doing a quick check first before a full start. E.g. No pom.groovy
>>> file .. exit.
>>> 
>>> The problem with using the settings file is that we then have two different
>>> syntax for specifiying the extensions and that we have to change settings so
>>> that would probably not be backwards compatible.. 
>>> 
>>> Manfred
>>> 
>>> Jason van Zyl wrote on 28.05.2015 05:08:
>>> 
>>>> So just to be clear you don't actually have to add the artifact itself but
a
>>>> declaration of the artifact and it will be downloaded. We really only first
>>>> thought about project specific extensions, making sure the mechanism worked
>>>> with the type of bootstrapping required, proper classloader isolation, that
a
>>>> complex project I was working on functioned, and that polyglot worked for
>>>> JRuby. We have discussed in the hangouts how an extension might work on an
>>>> organizational basis but never really decided anything. 
>>>> 
>>>> So how would an organization say they wanted to use the Groovy DSL? The POM
>>>> is
>>>> likely ideal but we have obvious bootstrapping issues doing that as you can
>>>> imagine with extensions like Polyglot which actually need to read the POM.

>>>> 
>>>> I think the options are:
>>>> 
>>>> - user level
>>>> - .m2/extensions.xml: i think it is hard here to enforce what projects to
>>>> operate on, i don't think you want the groovy extension loaded for every
>>>> project
>>>> 
>>>> - distribution level: you have to ensure that everyone actually uses the
same
>>>> distribution. this is possible with the Maven Wrapper
>>>> (http://github.com/takari/maven-wrapper)
>>>> 
>>>> - project level
>>>> - .mvn/extensions.xml: what is currently implemented
>>>> 
>>>> - organization level
>>>> - ${url}/extensions.xml: we need to use something outside the POM currently.
>>>> we might be able to get clever making a couple passes but we're not currently
>>>> doing that.
>>>> 
>>>> Jordan, what do you think would be most convenient and least error prone?
>>>> 
>>>> On May 27, 2015, at 2:52 PM, Jordan Zimmerman <jordan@jordanzimmerman.com>
>>>> wrote:
>>>> 
>>>>> What is the reason that .mvn/extensions.xml has to be added to every
>>>>> project?
>>>>> It would be much more useful to add it globally in the .m2 directory.
If I
>>>>> want to standardize, say, on Groovy polyglot I don’t want to have to
have
>>>>> every developer in our org remember to add the extension to every project.
>>>>> That would be a big pain.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>> 
>>>> In short, man creates for himself a new religion of a rational
>>>> and technical order to justify his work and to be justified in it.
>>>> 
>>>> -- Jacques Ellul, The Technological Society
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> What matters is not ideas, but the people who have them. Good people can fix
>> bad ideas, but good ideas can't save bad people. 
>> 
>> -- Paul Graham
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

The most dangerous risk: spending your life not doing what you want on the bet you can buy
yourself freedom to do it later.

 -- Randy Komisar












---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message