Now apply this to maven-scm if you like to have a test object. This sometimes gets built in one go, sometimes as single modules, ...
LieGrue, strub ----- Original Message ----- > From: Kristian Rosenvold <kristian.rosenv...@gmail.com> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Wednesday, September 5, 2012 9:31 AM > Subject: Re: Git as the canonical SCM > > I think we should move to git; probably starting with a few > repositories. I will not go into the argument as to why (it's been > covered like a zillion times, link by Andrew covers a lot of it), > other than to mention that the immense ease of moving around in > history means that I never have to consider a patch "stale" since I > can easily review it at the point in history it was created; > additionally there's a much-improved chance I can move this to the top > of history without being stale) > > Basically I've been meaning to start av vote suggesting that we: > > 1) Decide to move *all* maven projects to git, time frame subject to > project/asf/infra capacity. We're in no immense hurry. > 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones > (just to get the general feel for how things work) and a hard one. > Right now I'd suggest something like m3-core, surefire( or scm) and > maven-plugins, the last being the hard one ;) > > I herby volunteer to do the donkey-work, including some massive > filter-branch operations on the current asf maven-plugins git clone. > > I think we should split maven-plugins, because I think the solution > chosen is optimized for the wrong uses cases, and it only helps for > setting up CI jobs. The rest of the community basically has no value > in the current set-up. > > Which makes me think we should consider such a switch an opportunity > to re-think some of our tooling > around multi-module projects. What the 99% others want (who're not > setting up a CI) is a checkout algorithm that builds the *vertical* > stack for a given plugin, not the horizontal top-level stack for all > the plugins (which is what we have currently). So if I checkout > "maven-ear-plugin", I would basically want something like this: > root-dir\ > maven-ear-plugin\ > maven-archiver\ > maven-filtering\ > plexus-archiver\ > plexus-utils > .. maybe more.. (probably configurable somewhere) > > Now if the checkout would generate a synethetic parent pom with all > these as modules, I could just load it all up in IDEA and be ready to > go. I think something like this would have /real/ value to most of our > users, whereas the current maven-plugins layout really only is > valuable for whoever is configuring a CI to build maven-plugins. > > No matter what, I think there's very lfew practical use cases for > having all the modules chunked together. > > Kristian > > > 2012/9/4 Olivier Lamy <ol...@apache.org>: >> 2012/9/4 Andrew Waterman <awate...@ecosur.mx>: >>> The drools guys did a really nice move from Subversion a few years > back. >>> >>> http://blog.athico.com/2010/12/drools-migrated-to-git.html >>> >>> One of the key things they did, was reorganize their poms and project > structure. >>> >>> I'd be willing to help out. I think there could be a lot more to > this move than just importing from subversion, but it depends on what you > guys > want to do. >> >> Yup I agree. >> I use git on other oss projects (Apache: cloudstack and non Apache: >> jenkins ...) and git svn for some asf projects. >> Due to lack of support of sparse checkout in git, I (perso) don't want >> we have to create a git repo per plugin etc... >> IMHO That will be a pain to manage. >> >>> >>> best wishes, >>> >>> Andrew >>> >>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" > <jpye...@pdinc.us> wrote: >>> >>>>> -----Original Message----- >>>>> From: Jason van Zyl >>>>> Sent: Tuesday, September 04, 2012 15:55 >>>>> >>>>> How's Git doing at Apache these days? >>>>> >>>>> Anyone interested in pursuing putting Maven in Git as the >>>>> canonical SCM? >>>> >>>> Comments from the peanut gallery: It would make it very nice to > contribute back. >>>> Since I do not have a sandbox access I have thrown away fixes > because there was >>>> no efficient way to track them until they were accepted as patches. > (same >>>> problem in struts, commons, ...) >>>> >>>> We would be very happy here at PD Inc if that was done. >>>> >>>> -Jason Pyeron >>>> >>>> -- >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>> - - >>>> - Jason Pyeron PD Inc. http://www.pdinc.us - >>>> - Principal Consultant 10 West 24th Street #100 - >>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - >>>> - - >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>> This message is copyright PD Inc, subject to license 20080407P00. >>>> >>>> >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
