I have always a doubt about ITs maintenance if they are in the same repo as the core itself For Its we are not really releasing them nor we managed their versions. we took the trunk (or the master nowadays in git) and we launched them on a given maven version Now let's say that someone wants to solve a problem on a maintenance branch (thus not master) With git it will checkout this branch to work on the fix, but if in // he wants to add an IT it will add it on this branch (not on master where we should have all ITs ?) How many chance that one day we forgot to merge back ITs from all branches in master ? WDYT ?
On Thu, Oct 11, 2012 at 11:51 AM, Jason van Zyl <[email protected]> wrote: > Fair enough. I can't think of a reason not to try it. In Git it's easy to > change anything if it's not working out in practice. > > On Oct 11, 2012, at 5:40 AM, Kristian Rosenvold < > [email protected]> wrote: > > > 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 <[email protected]>: > >> > >> On Oct 11, 2012, at 3:44 AM, Mark Struberg <[email protected]> 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 <[email protected]> > >>>> To: Maven Developers List <[email protected]> > >>>> Cc: Mark Struberg <[email protected]> > >>>> 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 < > >>>> [email protected]> wrote: > >>>> > >>>>> On Thursday, 11 October 2012, Kristian Rosenvold wrote: > >>>>> > >>>>>> 2012/10/11 Mark Struberg <[email protected] > >>>> <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: [email protected] > >>>> <javascript:;> > >>>>>> For additional commands, e-mail: > >>>> [email protected]<javascript:;> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> ----- > >>>> Arnaud Héritier > >>>> 06-89-76-64-24 > >>>> http://aheritier.net > >>>> Mail/GTalk: [email protected] > >>>> Twitter/Skype : aheritier > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > > -- ----- Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: [email protected] Twitter/Skype : aheritier
