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 <manf...@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 <jor...@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-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
