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" <[email protected]> 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 ><[email protected]> 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: [email protected] >For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
