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