maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <>
Subject Re: Git as the canonical SCM
Date Wed, 05 Sep 2012 09:27:05 GMT
2012/9/5 Kristian Rosenvold <>:
> 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),
Yes we must avoid such buzz/troll to save our 'reading importants
emails' time :-) as we are sure git is a nice scm.
And this topic has been already enough discussed here it's time to
move forward on that !
I personally use only git (git svn for Apache).
And for sure using native git will save some of my cpu cycles and
network bandwidth :-) (git push or git fetch / rebase will be
certainly better than git svn dcommit or git svn rebase).

> 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 ;)
ASF infra ask volunteers from TLP projects which want to use git to
help on infra tasks related to git admin.
Perso I can but as I won't have enough cycles I'd like to see an other
volunteer. Kristian ?
IMHO we must start with maven-3 to improve participation from others
as it looks to be the goal and that will do more marketing/buzz than
moving scm or wagon :-).

I can start the vote (maybe a vote with a majority of +1 from committers)

> I herby volunteer to do the donkey-work, including some massive
> filter-branch operations on the current asf maven-plugins git clone.
Cool !
> 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.
Yup but that's more easy to maintain than a ton of jenkins jobs
> 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.
That's a good idea !!
What about a maven plugin for that ? :-)
checkout/clone your project then mvn sources:checkout-dependencies (or
clone-dependencies :-) ).
The plugin could have a look at dependencies scm section and if exists
checkout/clone the sources locally (we have all the necessary
components for that)

> 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 <>:
>> 2012/9/4 Andrew Waterman <>:
>>> The drools guys did a really nice move from Subversion a few years back.
>>> 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" <> 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
>>>> Since I do not have a sandbox access I have thrown away fixes because there
>>>> 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. -
>>>> - 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:
>>>> For additional commands, e-mail:
>> --
>> Olivier Lamy
>> Talend:
>> |
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Olivier Lamy
Talend: |

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message