You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2015/05/27 20:52:18 UTC
Why are extensions project based and not global?
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.
Re: Why are extensions project based and not global?
Posted by Hervé BOUTEMY <he...@free.fr>.
because if you want global extensions, there is a mechanism that exists for a
long time: put jar files in lib/ext
the new .mvn/extensions.xml feature is really about permitting non-global
extensions, to ease per-project tests before making the extensions global (and
if the extension is a strong requirement and not only an enhancement, add it
to the documentation for the team to make sure it doesn't work with stock
Maven but configured one)
so, it's not a bug, it's really a feature :)
Regards,
Hervé
Le mercredi 27 mai 2015 13:52:18 Jordan Zimmerman a écrit :
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why are extensions project based and not global?
Posted by "Lyons, Roy" <Ro...@cmegroup.com>.
Jason,
My 2 cents... The idea of organization-wide settings is not a new one. I
would be hard-pressed to find an organization that is not using a maven
repository internally and the distributed .m2/settings.xml seems like the
right place for this. Everyone in the organization has to have the right
entries in settings.xml for it to work, and most people can't be bothered
to run the plugin themselves to generate the settings - much less actually
hand edit a file to remove polyglot settings or something.
For instance, in order for any of your builds to work, you need to run
'mvn org.sonatype.plugins:nexus-m2settings-maven-plugin:1.6.5:download
-DtemplateId=OURTEMPLATEID'. That takes a template in Nexus and injects
an encrypted form of the token id and token password, saving it to the
user's .m2/settings.xml
Since settings.xml is not polyglot - it is also a safe place to put it!
So:
<settings>
<mirrors />
<pluginGroups />
<servers />
<proxies />
<profiles />
<!-- And now the new section! -->
<extensions />
</settings>
Thanks,
Roy Lyons
Sr. Software Configuration Management Engineer
Next Chicago Atlassian User Group meeting:
http://aug.atlassian.com/cities/chicagoil
On 5/28/15, 7:08 AM, "Jason van Zyl" <ja...@takari.io> wrote:
>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
><jo...@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
Re: Why are extensions project based and not global?
Posted by Jason van Zyl <ja...@takari.io>.
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 <ma...@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 <ma...@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 <jo...@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
Re: Why are extensions project based and not global?
Posted by Manfred Moser <ma...@mosabuam.com>.
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 <ma...@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 <jo...@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
Re: Why are extensions project based and not global?
Posted by Jason van Zyl <ja...@takari.io>.
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 <ma...@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 <jo...@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
Re: Why are extensions project based and not global?
Posted by Manfred Moser <ma...@mosabuam.com>.
Use cases I can think of (there are probably more)
- use concurrent safe local repo access for all builds on a CI server without having to modify all projects
- enabling extension for multi thread logging or any other feature like coloring or so across all projects I work on locally
- allow different pom DSL's even when creating a new project and .mvn/extensions.xml was not yet added
- easily manage version of extensions to be used across a number of projects
- allow to take advantage of extensions even when you dont have full access to a project repository
I am not certain these justify the problems you mention .. which is why I think we should just let the usage of extensions get wider before we make any decisions.
Manfred
Graham Leggett wrote on 28.05.2015 11:21:
> On 28 May 2015, at 16:58, Manfred Moser <ma...@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.
>
> Can you describe the use case?
>
> It seems this only makes sense if you only ever do work for one organization,
> ever. As soon as you need to do work for multiple clients, or perhaps your
> corporate client and an open source project, using maven becomes difficult.
>
> Even with a single organization having config outside the project is a right
> pain. Instead of "it's maven, you know what to do", you have some weird site
> specific ritual to perform, and this creates friction.
>
> Regards,
> 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
Re: Why are extensions project based and not global?
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi,
> Even with a single organization having config outside the project is a
> right pain. Instead of "it's maven, you know what to do", you have
> some weird site specific ritual to perform, and this creates friction.
FWIW, in general, I agree 100%. One of the beautiful things about Maven is
that for every project, you can:
$ git clone git://github.com/myorg/myproj
$ cd myproj
$ mvn
And good things happen! So awesome!
As soon as you also have to start tweaking ~/.m2/settings.xml or
settings-security.xml or extensions.xml or whatever, the beauty is gone...
Regards,
Curtis
On Thu, May 28, 2015 at 1:21 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 28 May 2015, at 16:58, Manfred Moser <ma...@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.
>
> Can you describe the use case?
>
> It seems this only makes sense if you only ever do work for one
> organization, ever. As soon as you need to do work for multiple clients, or
> perhaps your corporate client and an open source project, using maven
> becomes difficult.
>
> Even with a single organization having config outside the project is a
> right pain. Instead of "it's maven, you know what to do", you have some
> weird site specific ritual to perform, and this creates friction.
>
> Regards,
> Graham
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Why are extensions project based and not global?
Posted by Graham Leggett <mi...@sharp.fm>.
On 28 May 2015, at 16:58, Manfred Moser <ma...@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.
Can you describe the use case?
It seems this only makes sense if you only ever do work for one organization, ever. As soon as you need to do work for multiple clients, or perhaps your corporate client and an open source project, using maven becomes difficult.
Even with a single organization having config outside the project is a right pain. Instead of "it's maven, you know what to do", you have some weird site specific ritual to perform, and this creates friction.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why are extensions project based and not global?
Posted by Manfred Moser <ma...@mosabuam.com>.
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 <jo...@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
Re: Why are extensions project based and not global?
Posted by Jason van Zyl <ja...@takari.io>.
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 <jo...@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