I think the key argument for adding the IT's to the "maven" core repo is that it makes it so much easier to maintain high quality forks, a scenario I think we should fully embrace since it's also a gateway point for high-quality contributions.
Having maintained quite extensive forks of several *large* OSS frameworks for some years in git, I think the forker has a "goal" of knowing exactly what the difference is between her fork and the mainline. As the mainline evolves, I think it's crucial for the forker to be able to evolve. Keeping the IT's together with the code makes it a lot easier to keep track of which changes a fork actually contain, since the branch effectively contains not only core changes but also IT changes. The IT's determine how "maven-like" your fork is. The forker can maintain a clear notion of this by changing his forked IT's too. You have this great tool for asserting the quality of the work/fork and you decide to make it twice as hard to use by keeping them in separate repos. Most of the stuff you refer to is simply the way things have been done up to now. The "coupling" concern is the only one that I feel has some technical backing. A different "technical" argument is that if we add the IT's to the core repo, we could choose to run some of them as part of a regular "clean install" build. We have done this with great success on some in-house projects; tag the IT's with JUnit @Category "minimal" test suite and have that run with the main build. So I say m2+m3+it's in one repo is a neat solution. The ability to test "other" mavens will be there no matter what ;) Kristian 2012/10/11 Jason van Zyl <ja...@tesla.io>: > > On Oct 11, 2012, at 3:44 AM, Mark Struberg <strub...@yahoo.de> wrote: > >> As I see it after the feedback there are 2 main arguments: >> >> * maintaining the ITs during maven-core development. People currently tend >> to forget adding ITs for the stuff they change. This might be easier if the >> ITs are contained in the same repo. >> >> * being able to run the ITs onto old maven releases. That's for sure easier >> if we keep em separated. >> >> >> Any other arguments to add to the list? >> > > - they do not have the same lifecycle > - the are designed to be separate > - coupling will most certainly happen if people work on them simultaneously > >> >> I'm perfectly fine either way. It's just that we can change this easily >> right now and it might be harder to do later. >> > >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Arnaud Héritier <aherit...@gmail.com> >>> To: Maven Developers List <dev@maven.apache.org> >>> Cc: Mark Struberg <strub...@yahoo.de> >>> Sent: Thursday, October 11, 2012 9:32 AM >>> Subject: Re: Flipping Maven Core to Git >>> >>> Like Stephen I would prefer to keep them separated. >>> They have a different lifecycle as we should be (we are ?) able to run ITs >>> against various versions of Maven and we take care to have flags to >>> enable/disable some tests. >>> I see no advantage to merge them >>> For me the need to reduce the number of repositories is like the need to >>> reduce the number of Jira projects. It's only a sysadmin constraint and it >>> is against the spirit of these tools. >>> >>> Arnaud >>> >>> >>> On Thu, Oct 11, 2012 at 9:07 AM, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> >>>> On Thursday, 11 October 2012, Kristian Rosenvold wrote: >>>> >>>>> 2012/10/11 Mark Struberg <strub...@yahoo.de >>> <javascript:;>>: >>>>>> What if we first merge the 2 repos into 1 git repo? >>>>>> >>>>>> Imo maven-core and the ITs must fit together! Having the ITs in a >>>>> separate repo will make people forget about them. >>>>> >>>>> None of them are big, we could easily merge them; conceptually they >>>>> belong together. It would seem like they should be merged with the >>>>> same source root. I assume the best way to do this would simply be to >>>>> flip m3 to git, then just add the complete history of core-its and >>>>> then just "merge" them on trunk... ? >>>>> >>>>> >>>>>> >>>>>> Also for a maven-core release it isn't a problem if the ITs >>> get tagged. >>>>> I actually would even really appreciate that fact! >>>>> >>>>> Each core iIT is tagged with the initial maven version which it is >>>>> valid at (using a homebrew replacement of JUnit assumptions), which >>>>> means the full IT suite is self-configuring wrt which maven version it >>>>> is being run against. No need to tag it really. >>>> >>>> >>>> I would actually prefer that the it suite is separate as it is version >>>> independent. >>>> >>>> But I don't feel strongly either way >>>> >>>>> >>>>> Kristian >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> <javascript:;> >>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org<javascript:;> >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> ----- >>> Arnaud Héritier >>> 06-89-76-64-24 >>> http://aheritier.net >>> Mail/GTalk: aherit...@gmail.com >>> Twitter/Skype : aheritier >>> >> >> --------------------------------------------------------------------- >> 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 & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
