Sorry to hear that you have no fun hacking here anymore. But just to share some thoughts about the groovy-maven stuff. I can certainly see that there was lots of bad timing around on both sides in those days. But the argument for _not_ checking this in to maven 1:1 was mainly because this feature
a.) doesn't really fit 100% with the declarative approach of maven but is more the old 'imperative' one. The very explicit idea was always to only do imperative tasks in plugins and _not_ in a normal project description. b.) it imo doesn't work out to throw 2 years of outside work onto a COMMUNITY which had no way to make any decisions but should rather 'take it as is or leave it'. This stuff is fairly complex and has lots of dependencies and impact. It would have been needed to do a complete IP sanity check, check all the projects history, identify and rewrite all outside contributions, review the used pattern, build some community, etc etc. I don't like to stress that there would have been better ways to improve maven in this direction, because we all know that there is not always the perfect time for this stuff. Afair our response was exactly that: we would need much more time to incorporate this properly and we will for sure _not_ pull this stuff in 1:1 before we have a detailed clue what it does. You also don't eat stuff where you have no clue what is in it, right? LieGrue, strub ----- Original Message ----- > From: Jason van Zyl <ja...@tesla.io> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Thursday, May 10, 2012 1:15 AM > Subject: Re: Plugins with Annotations ETA > > > On May 9, 2012, at 3:30 PM, Mark Derricutt wrote: > >> On 10/05/12 7:47 AM, Jason van Zyl wrote: >>> The only thing I would like to sync up on is a couple changes I want to > make to the plugin manager to make sure the current plugin packaging, the > plugin > packaging you're making and the plugin packaging I'm working on in Tesla > all work together without conflicting. Anyone should theoretically be able to > make a toolchain and allow users to take >> Is there any intent to merge any of the etesla stuff back into Apache Maven > core at all? ( I'd really love to see Atom POM in some 'official > blessed' manner ). > > I plan to do the odd patch and help with extensibility for what I would like > to > do in Tesla, but as far as merging the work no plans. Apache nearly expunged > all > my passion for innovating and doing open source in general. I've been happy > again lately hacking with folks like Dhanji and I personally don't plan to > contribute anything significant to Apache ever again. I speak here purely for > myself. The overhead for innovating at Apache is just too high for me. Maven > has > stagnated and I believe that's fairly visible to most users and I can't > really do anything about that from Apache. But I can from Tesla, and I've > enjoyed how Tesla has gone and I plan to continue working this way. I'm > having fun again and I can contribute to the ecosystem when I enjoy what I'm > doing. > > As far as Tesla goes and how it relates to builds it is a set of add-ons to > Maven. I have a couple small patches for the core to contribute back, but if > you > want to take advantage of build stuff in Tesla it's just adding some JARs to > the distribution. But Tesla is not only about builds. I am building > integration > across the build, IDE, repository manager, CI, provisioning and software > delivery in general. My work now I would categorize as being interested in > the > continuity across all the tools and the build is a small part of that. I can > move faster working by myself and selectively working with folks like > Dhanji, > Dain and Jeanfrancois. > > The core of Maven has been modified to the point where it is fully extensible > purely by the addition of JARs. Further to that Igor has created a mechanism > that allows extension by configuration so that upon startup Maven can alter > its > functionality by downloading new extensions on the fly. This Sonatype is > likely > to contribute back and once that is done anyone should be able to extend > Maven > easily whether it be for individual use or for thousands of developers within > a > corporation. > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > the course of true love never did run smooth ... > > -- Shakespeare > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
