maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@tesla.io>
Subject Re: Git as the canonical SCM
Date Wed, 05 Sep 2012 13:22:33 GMT
+1

All reasonable, and we can certainly try it with a few repos people are interested. 

On Sep 5, 2012, at 3:31 AM, Kristian Rosenvold wrote:

> 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 <olamy@apache.org>:
>> 2012/9/4 Andrew Waterman <awaterma@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" <jpyeron@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message