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