subject:"Maven Core to Git"

Kristian/Olivier,

What exactly is the issue with switching over the core to Git? I only know 
vaguely what the reasoning is because I happened to wander into IRC one day. I 
also see the Jenkins issue[1] referred to in the Infra issue[2] about the 
conversion but it's not clear what's happening there or if it will be fixed 
anytime soon. What exactly is the problem? And why doesn't this behaviour 
exhibit itself in some of the other Git repos we have being built under 
Jenkins? I see tons of other projects using Git and Jenkins so can we 
workaround anything specific we're doing?

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

The problem is the asf builds running too often, and sometimes far too
often and hence spamming the mailing lists substantially. Some of it
has been solved, but there are still a few issues remaniing:

As far as I can see there are two aspects of the issue:

1. A configuration error (or any kind of git corruption/inconsistency)
on any of the git nodes would lead to the jenkins build running
non-stop, generating mass amounts of spam on the notifications mailing
lists. This issue has been solved as far as I can see; both by fixing
the git configuration issue and by patching jenkins to fix the issue.
This was https://issues.jenkins-ci.org/browse/JENKINS-15803.

2. There is a second issue where any kind of intermittent disconnect
between the main jenkins instance and its node will trigger a rebuild
because the master does not distinguish between a node being
blank/reconfigured and simply unavaliable at the moment.

This is basically happening by workspaceOffline returning true in
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437

I've been meaning to get Olivier to add logging in this code to find
out what is actually happening. It seems to
me like every single glitch in the asf network is causing rebuilds.
And it would appear to be a quite unstable network

Kristian

2012/11/26 Jason van Zyl ja...@tesla.io:
Kristian/Olivier,

What exactly is the issue with switching over the core to Git? I only know
vaguely what the reasoning is because I happened to wander into IRC one day.
I also see the Jenkins issue[1] referred to in the Infra issue[2] about the
conversion but it's not clear what's happening there or if it will be fixed
anytime soon. What exactly is the problem? And why doesn't this behaviour
exhibit itself in some of the other Git repos we have being built under
Jenkins? I see tons of other projects using Git and Jenkins so can we
workaround anything specific we're doing?

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:

As far as I can see there are two aspects of the issue:

This is basically happening by workspaceOffline returning true in
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437

So in practical terms it all needs to be released, and the servers all updated?

Can we just turn off the remote nodes for the time being and just run
1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer to
do that in the short term because getting this all this working doesn't seem
like it's going to happen very quickly.

Kristian

2012/11/26 Jason van Zyl ja...@tesla.io:
Kristian/Olivier,

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

-
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
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob Burckhardt

Re: Maven Core to Git

2012-11-26 Thread Dennis Lundberg

On 2012-11-26 15:59, Jason van Zyl wrote:

On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:

As far as I can see there are two aspects of the issue:

This is basically happening by workspaceOffline returning true in
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437

So in practical terms it all needs to be released, and the servers all
updated?

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Can we just turn off the remote nodes for the time being and just run
1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer
to do that in the short term because getting this all this working doesn't
seem like it's going to happen very quickly.

Which ubuntu node would that be? There are 5 of them and I think they
are all slaves.

Apart from these issues I proposed that we release a couple of our own
products using git, before we move the core over to git. Just so that we
have a good grasp of how a Maven release using git is done and get it
properly documented. I'm not up to date on the progress here though.
Would those of you that have done such releases please let us know?

Kristian

2012/11/26 Jason van Zyl ja...@tesla.io:
Kristian/Olivier,

What exactly is the issue with switching over the core to Git? I only know
vaguely what the reasoning is because I happened to wander into IRC one
day. I also see the Jenkins issue[1] referred to in the Infra issue[2]
about the conversion but it's not clear what's happening there or if it
will be fixed anytime soon. What exactly is the problem? And why doesn't
this behaviour exhibit itself in some of the other Git repos we have being
built under Jenkins? I see tons of other projects using Git and Jenkins so
can we workaround anything specific we're doing?

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

-
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
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob Burckhardt

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

On Nov 26, 2012, at 10:41 AM, Dennis Lundberg denn...@apache.org wrote:

On 2012-11-26 15:59, Jason van Zyl wrote:

On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:

As far as I can see there are two aspects of the issue:

This is basically happening by workspaceOffline returning true in
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437

So in practical terms it all needs to be released, and the servers all
updated?

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Can we just turn off the remote nodes for the time being and just run
1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer
to do that in the short term because getting this all this working doesn't
seem like it's going to happen very quickly.

Which ubuntu node would that be? There are 5 of them and I think they
are all slaves.

Just run on one machine for the matrix of JDKs we care about if this prevents
the build explosions.

Apart from these issues I proposed that we release a couple of our own
products using git, before we move the core over to git.

We have already haven't we? Apart from that I've done hundreds of releases out
of Git and it works fine. But for core I will take responsibility if the buck
needs to stop somewhere. I just want to get it moved over and work around any
issues until the problems are solved.

Just so that we
have a good grasp of how a Maven release using git is done and get it
properly documented. I'm not up to date on the progress here though.
Would those of you that have done such releases please let us know?

The release plugin works fine with Git.

Kristian

2012/11/26 Jason van Zyl ja...@tesla.io:
Kristian/Olivier,

What exactly is the issue with switching over the core to Git? I only know
vaguely what the reasoning is because I happened to wander into IRC one
day. I also see the Jenkins issue[1] referred to in the Infra issue[2]
about the conversion but it's not clear what's happening there or if it
will be fixed anytime soon. What exactly is the problem? And why doesn't
this behaviour exhibit itself in some of the other Git repos we have being
built under Jenkins? I see tons of other projects using Git and Jenkins so
can we workaround anything specific we're doing?

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

-
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
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob

Re: Maven Core to Git

2012-11-26 Thread Dennis Lundberg

On 2012-11-26 19:49, Jason van Zyl wrote:

On Nov 26, 2012, at 10:41 AM, Dennis Lundberg denn...@apache.org wrote:

On 2012-11-26 15:59, Jason van Zyl wrote:

On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:

As far as I can see there are two aspects of the issue:

This is basically happening by workspaceOffline returning true in
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437

So in practical terms it all needs to be released, and the servers all
updated?

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Can we just turn off the remote nodes for the time being and just run
1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer
to do that in the short term because getting this all this working doesn't
seem like it's going to happen very quickly.

Which ubuntu node would that be? There are 5 of them and I think they
are all slaves.

Just run on one machine for the matrix of JDKs we care about if this prevents
the build explosions.

Apart from these issues I proposed that we release a couple of our own
products using git, before we move the core over to git.

We have already haven't we? Apart from that I've done hundreds of releases
out of Git and it works fine. But for core I will take responsibility if the
buck needs to stop somewhere. I just want to get it moved over and work
around any issues until the problems are solved.

Like I said, I don't know the current status on this. It might very well
be that we are there now.

The release plugin works fine with Git.

I'm sure it does. But for git beginners like myself who has not done a
single release using git, we need a well documented release process for it.

Kristian

2012/11/26 Jason van Zyl ja...@tesla.io:
Kristian/Olivier,

What exactly is the issue with switching over the core to Git? I only
know vaguely what the reasoning is because I happened to wander into IRC
one day. I also see the Jenkins issue[1] referred to in the Infra
issue[2] about the conversion but it's not clear what's happening there
or if it will be fixed anytime soon. What exactly is the problem? And why
doesn't this behaviour exhibit itself in some of the other Git repos we
have being built under Jenkins? I see tons of other projects using Git
and Jenkins so can we workaround anything specific we're doing?

[1]: https://issues.jenkins-ci.org/browse/JENKINS-15803
[2]: https://issues.apache.org/jira/browse/INFRA-5390

Thanks,

Jason

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

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

-
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

Re: Maven Core to Git

2012-11-26 Thread Kristian Rosenvold

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Additionally, there is
https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in
remoting
4 days ago. According to the issue text it renders the slaves
unusable. To which extent that makes the
remote poller crash out is also unknown. But it's known that we have
a *lot* of 6604 on the nodes,
especially right after a restart. I am unsure what effect a single
bad apple among the remote nodes
has and to what extent we would detect it.

Reading the jenkins code makes me quite sure that any build that is locked to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354)
to be non-null but that should stop the random reallocations. I assume we could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

2012-11-26 Thread Stephen Connolly

Kristian, can you ping me on irc tomorrow and maybe I can put some time
into sorting the issues out (from the Jenkins side)

On Monday, 26 November 2012, Kristian Rosenvold wrote:

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Reading the jenkins code makes me quite sure that any build that is locked
to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354
)
to be non-null but that should stop the random reallocations. I assume we
could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
For additional commands, e-mail: dev-h...@maven.apache.org javascript:;

Re: Maven Core to Git

2012-11-26 Thread Benson Margulies

On the jenkins question, Why don't all the other Apache projects for
which I'm on the dev list suffer from this?

On the RM question, I don't think it's worth waiting. The core is the
thing we release least often. We've run a release or two on the
components we've already migrated, and whomever runs the first core
release from git can be sure to add notes to the doc.

On Mon, Nov 26, 2012 at 2:44 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Kristian, can you ping me on irc tomorrow and maybe I can put some time
into sorting the issues out (from the Jenkins side)

On Monday, 26 November 2012, Kristian Rosenvold wrote:

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Reading the jenkins code makes me quite sure that any build that is locked
to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354
)
to be non-null but that should stop the random reallocations. I assume we
could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
For additional commands, e-mail: dev-h...@maven.apache.org javascript:;

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

Agree. Shit happens, we'll deal with it. For now let's just lock it down to one
machine. We can also just setup individual builds on the separate machines. No
big deal.

jvz

On 2012-11-26, at 11:18 AM, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:

There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Reading the jenkins code makes me quite sure that any build that is locked to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354)
to be non-null but that should stop the random reallocations. I assume we
could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

2012-11-26 Thread Dennis Lundberg

On 2012-11-26 20:18, Kristian Rosenvold wrote:
There is also
https://issues.jenkins-ci.org/browse/JENKINS-15367
which went into Jenkins 1.492 that was released yesterday, that may or
may not be a factor in this depending who you talk to.

Reading the jenkins code makes me quite sure that any build that is locked to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354)
to be non-null but that should stop the random reallocations. I assume we
could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Thanks Kristian, that's all I wanted to hear. Please go ahead and convert.

Just remember to document any differences between svn and git along the way.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Core to Git

I'm going to be working on the core for a few weeks. I am not convinced putting
the ITs with the core is workable. I've tried it with a few scenarios and it's
super confusing to me at least.

If you're going to convert them, can you please keep them as individual
repositories for now and I'd like to work with you through some use cases
because I ran into some problems but you may have ways to work around them. I
would prefer to merge them together later then assume it will work and have to
undo it.

On Nov 26, 2012, at 1:41 PM, Dennis Lundberg denn...@apache.org wrote:

Reading the jenkins code makes me quite sure that any build that is locked to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354)
to be non-null but that should stop the random reallocations. I assume we
could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Thanks Kristian, that's all I wanted to hear. Please go ahead and convert.

Just remember to document any differences between svn and git along the way.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
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
-

The modern conservative is engaged in one of man's oldest exercises in moral
philosophy; that is,
the search for a superior moral justification for selfishness.

-- John Kenneth Galbraith

Re: Maven Core to Git

2012-11-26 Thread Arnaud Héritier

On Mon, Nov 26, 2012 at 11:20 PM, Jason van Zyl ja...@tesla.io wrote:

I'm going to be working on the core for a few weeks. I am not convinced
putting the ITs with the core is workable. I've tried it with a few
scenarios and it's super confusing to me at least.

If you're going to convert them, can you please keep them as individual
repositories for now and I'd like to work with you through some use cases
because I ran into some problems but you may have ways to work around them.
I would prefer to merge them together later then assume it will work and
have to undo it.

On Nov 26, 2012, at 1:41 PM, Dennis Lundberg denn...@apache.org wrote:

Reading the jenkins code makes me quite sure that any build that is
locked to
1 specific node will not encounter any of the network-down issues. I
don't really understand
how to get assignedNode
(
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354
)
to be non-null but that should stop the random reallocations. I assume
we could
lock a few of the jobs down to given nodes and keep some open while we
continue to track the problem ?

Apart from these issues I proposed that we release a couple of our own
products using git, before we move the core over to git. Just so that
we
have a good grasp of how a Maven release using git is done and get it
properly documented. I'm not up to date on the progress here though.
Would those of you that have done such releases please let us know?

I believe all wagon, surefire and scm have all been released from git,
so I think we're in the clear on /that/ particular aspect.

Personally I think we should go ahead and convert core too.

Thanks Kristian, that's all I wanted to hear. Please go ahead and
convert.

Just remember to document any differences between svn and git along the
way.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
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
-

The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is,
the search for a superior moral justification for selfishness.

-- John Kenneth Galbraith

--
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: Maven Core to Git

2012-11-26 Thread Brett Porter


On 27/11/2012, at 10:34 AM, Arnaud Héritier aherit...@gmail.com wrote:

 On Mon, Nov 26, 2012 at 11:20 PM, Jason van Zyl ja...@tesla.io wrote:
 
 I'm going to be working on the core for a few weeks. I am not convinced
 putting the ITs with the core is workable. I've tried it with a few
 scenarios and it's super confusing to me at least.
 
 
 +1

Agree - makes sense to keep them separate as they are often run against 
different versions of Maven.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Summary: Flipping Maven Core to Git

2012-11-10 Thread Jason van Zyl

So we're almost at 4 weeks now. Does anyone know internally what's happening 
with:

https://issues.apache.org/jira/browse/INFRA-5390

On Oct 13, 2012, at 7:14 AM, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 After a very interesting discussion (which basically proves that community
 rocks IMO ;) I have created the following JIRA:
 
 https://issues.apache.org/jira/browse/INFRA-5390
 
 Once this has gone r/w, we will merge in the existing M2 and IT repo.
 
 If we at a later stage decide that merging the IT's was undesirable, we can
 filter them back out into a separate repository.
 
 Kristian

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

Re: Flipping Maven Core to Git

2012-10-13 Thread Kristian Rosenvold

Given the general amount of attention that the community gives core changes,
I think there is little reason to fear uncontrolled IT changes.

Simply put; my fear of IT's *not* getting updated/maintained far exceeds my
fear
of an erronous update creeping in (which is why in surefire the IT's run by
default with
no option to turn them off other than -DskipTests ;)

It seems to me we've covered all the important bases on this one; I'll
summarize
breiefly in a separate mail.

Kristian



2012/10/12 Igor Fedorenko i...@ifedorenko.com

 Although I understand we can make the merged repository work, at least
 with some discipline from developers, I think merged source repository
 makes changes to the integration tests perceptually okay, which imho
 is rarely the case. I actually maintained fork of maven ITs for
 awhile, and personally I did not find it too much trouble. At least as
 long as I was only adding new ITs, not changing existing ones.

 Just my 2c.

 --
 Regards,
 Igor


 On 12-10-12 3:47 AM, Kristian Rosenvold wrote:

 My mails came out sort-of in the wrong order, and I'm not sure if I agree
 with myself on splitting it changes - core changes.

 There is no technical mandate for this, not even a practical one since
 establishing mergeability from 2.2.1 - 3.X turned out to be simple.

 But as a personal work habit it's smart, because it allows you to change
 your mind easily.

 Let's say I want to fix MNG- on 3.X. I make an IT from a submitted
 sample project and I commit that on the 3.X branch.
 Now someone really wants that fixed back on 2.2.1, and it turns out the
 backport is real simple. All they need to do is cherry pick the IT and the
 core change back to 2.2.1. The IT always cherry-picks cleanly (more or
 less
 by definition due to the way we make IT's), but the core change does not,
 so the fix had to be re-applied on 2.2.1. When we merge 2.2.1 back to 3.X,
 git will automatically understand that the cherry-picked IT exists in the
 future and it won't trouble me with it. If the core change had been part
 of the IT commit I would lose this benefit, since the diffs become
 different (lol).

 (A diff that already exists in the history won't be reapplied, which is
 why
 it's so good to move *complete* commits backwards in time).

 Kristian


 2012/10/12 Arnaud Héritier aherit...@gmail.com

  It may still be a good idea to do IT and core-change as two different
 commits
 If we merge core and ITs I think it will be important to do it (and thus
 to
 ask it to contributors - or we'll need to do it on our side).
 I always see few reasons to merge them and find the process a little bit
 complex (especially if the committer isn't a Git Guru) but I admit that I
 won't bit impacted by this choice as my core contributions were (and will
 probably continue to be) near to nothing.
 Even if I really support the Git migration I don't want that we decrease
 the ability to contribute (it is already a big issue)

 Arnaud

 On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

  Btw; this simplifies the overall workflow to: Check out the oldest

 version

 you want to support this feature and add your IT + change there. It may
 still be a good idea to do IT and core-change as two different commits

 Kristian


 2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

  I could not resist, I made this repo and it works well: git clone
 https://github.com/krosenvold/**maven-rc.githttps://github.com/krosenvold/maven-rc.git

 It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's

 were

 added at 2.2.1 and merged up to 3.X. Which means we have a straight

 merge

 based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported

 for

 this mode of operation.

 Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand

 once

 we flip. Also; the pom.xml and the site in this merged repo contain

 only

 the  core pom (changes from core-its pom.xml and site will have to be
 merged by hand)

 Btw: In this repo, you can  checkout trunk (3.X and do git diff

 ...2.2.X

 and see what changes have been added to 2.2.X. Note three ...'s)

 Kristian


 2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

  NIce use case, this is where things get interesting ;) Initially I'll
 just add that this is one of those workflows that might be easier

 with a

 separate IT repo. This is how the flow would be in a merged single

 repo:


 This workflow has two distinct modes of operation:

 1. You always check out the oldest appropriate branch to make the IT.

 So

 if the IT should apply to 2.2.1 you should check that out. (If we need

 to

 make IT's that go even further back I think it might be easiest to

 just

 keep the IT's in a separate repo since it gets really hard to actually
 *make* that repo.)

 2 A) You are working in a properly branched structure that is

 mergeable

 ; i.e. what we might do between 3.0.X and 3.1 or maybe more

 appropriately

Summary: Flipping Maven Core to Git

2012-10-13 Thread Kristian Rosenvold

After a very interesting discussion (which basically proves that community
rocks IMO ;) I have created the following JIRA:

https://issues.apache.org/jira/browse/INFRA-5390

Once this has gone r/w, we will merge in the existing M2 and IT repo.

If we at a later stage decide that merging the IT's was undesirable, we can
filter them back out into a separate repository.

Kristian

Re: Flipping Maven Core to Git

2012-10-12 Thread Kristian Rosenvold

I could not resist, I made this repo and it works well: git clone
https://github.com/krosenvold/maven-rc.git

It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's were
added at 2.2.1 and merged up to 3.X. Which means we have a straight merge
based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported for
this mode of operation.

Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand once we
flip. Also; the pom.xml and the site in this merged repo contain only the
 core pom (changes from core-its pom.xml and site will have to be merged
by hand)

Btw: In this repo, you can  checkout trunk (3.X and do git diff ...2.2.X
and see what changes have been added to 2.2.X. Note three ...'s)

Kristian

2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

 NIce use case, this is where things get interesting ;) Initially I'll just
 add that this is one of those workflows that might be easier with a
 separate IT repo. This is how the flow would be in a merged single repo:

 This workflow has two distinct modes of operation:

 1. You always check out the oldest appropriate branch to make the IT. So
 if the IT should apply to 2.2.1 you should check that out. (If we need to
 make IT's that go even further back I think it might be easiest to just
 keep the IT's in a separate repo since it gets really hard to actually
 *make* that repo.)

 2 A) You are working in a properly branched structure that is mergeable
 ; i.e. what we might do between 3.0.X and 3.1 or maybe more appropriately
 between 3.X and 4.X.

 Make all the changes your heart desires, in any kind of commit sequence
 you prefer. The downstream merge to the subsequent version will fix it all.

 2 B) You are working i an unmergable branch structure (2.2.1-3.0)

 Add the IT as a distinct commit on the 2.2.1 branch, make sure any bug-fix
 you do is done as a separate commit from the IT. When done, you will need
 to check out the 3.0.X branch and cherry pick the commit with the  IT. From
 3.0.X on it will merge properly. cherry-picking is a manual operation and
 if you forget it, the IT will be lost on 2.2.1

 While this all may seem a bit complex, it's basically the nuts  bolts of
 how day-to-day life of a branched workflow functions. When working in older
 history, it's usually wise to partition work into well-defined commits,
 because sometimes you might end up cherry-picking only parts of the work
 forward. When you're on trunk you usually don't need to worry about this
 stuff.

 {begin Theoretical Technical digression for the git-savy}
 Theoretically we should be able to make a single phoney merge commit
 that re-establishes the mergeability between the 2.2.1 and 3.0.X branch so
 that any subsequent changes we make to 2.2.1 can merge directly downstream.
 I have not done this in practice but I'm sure some others here have. I'm
 thinking something like this:
 git checkout maven3.0.X
 git merge -s ours origin/maven-2.2.1

 Now of course I want to test this out before we proceed
 {end Theoretical Technical digression for the git-savy}


 Kristian


 2012/10/11 Jason van Zyl ja...@tesla.io

 Say I have the following scenario:

 I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x and
 create some ITs. What's the plan with making sure that we have one cohesive
 set of ITs that we can use across all versions? Just merge additions back
 into every branch? Because we would need to checkout two copies in order to
 be at one branch for the version of Maven you're working on and the branch
 where the ITs are. I understand wanting a rationalized fork and with unit
 tests I understand, but did you forks of large OSS projects include ITs
 like this?

 If that workflow is sorted out it seems fine. I just don't want it to be
 onerous to achieve the discipline of having on coherent set of tests that
 work across all versions of Maven. It's pretty easy to make that consistent
 right now. There's not a huge number of branches so merging additions back
 to each branch is pretty easy. Is that what you had in mind?


 On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

  2012/10/11 Arnaud Héritier aherit...@gmail.com
 
  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 ?
 
 
  If you make any kind of change on a branch (bugfix/feature/whatever) I
  would
  expect to have test updates being done on that branch too, so the branch
  represents a complete diff of the change; both feature and tests.
 
  When the fix/feature is merged back into master the tests come along, if
  the feature is
  never merged to master, the tests stay in their branch - just like they
  should.

Re: Flipping Maven Core to Git

2012-10-12 Thread Kristian Rosenvold

Btw; this simplifies the overall workflow to: Check out the oldest version
you want to support this feature and add your IT + change there. It may
still be a good idea to do IT and core-change as two different commits

Kristian


2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

 I could not resist, I made this repo and it works well: git clone
 https://github.com/krosenvold/maven-rc.git

 It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's were
 added at 2.2.1 and merged up to 3.X. Which means we have a straight merge
 based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported for
 this mode of operation.

 Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand once
 we flip. Also; the pom.xml and the site in this merged repo contain only
 the  core pom (changes from core-its pom.xml and site will have to be
 merged by hand)

 Btw: In this repo, you can  checkout trunk (3.X and do git diff ...2.2.X
 and see what changes have been added to 2.2.X. Note three ...'s)

 Kristian


 2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

 NIce use case, this is where things get interesting ;) Initially I'll
 just add that this is one of those workflows that might be easier with a
 separate IT repo. This is how the flow would be in a merged single repo:

 This workflow has two distinct modes of operation:

 1. You always check out the oldest appropriate branch to make the IT. So
 if the IT should apply to 2.2.1 you should check that out. (If we need to
 make IT's that go even further back I think it might be easiest to just
 keep the IT's in a separate repo since it gets really hard to actually
 *make* that repo.)

 2 A) You are working in a properly branched structure that is mergeable
 ; i.e. what we might do between 3.0.X and 3.1 or maybe more appropriately
 between 3.X and 4.X.

 Make all the changes your heart desires, in any kind of commit sequence
 you prefer. The downstream merge to the subsequent version will fix it all.

 2 B) You are working i an unmergable branch structure (2.2.1-3.0)

 Add the IT as a distinct commit on the 2.2.1 branch, make sure any
 bug-fix you do is done as a separate commit from the IT. When done, you
 will need to check out the 3.0.X branch and cherry pick the commit with the
  IT. From 3.0.X on it will merge properly. cherry-picking is a manual
 operation and if you forget it, the IT will be lost on 2.2.1

 While this all may seem a bit complex, it's basically the nuts  bolts of
 how day-to-day life of a branched workflow functions. When working in older
 history, it's usually wise to partition work into well-defined commits,
 because sometimes you might end up cherry-picking only parts of the work
 forward. When you're on trunk you usually don't need to worry about this
 stuff.

 {begin Theoretical Technical digression for the git-savy}
 Theoretically we should be able to make a single phoney merge commit
 that re-establishes the mergeability between the 2.2.1 and 3.0.X branch so
 that any subsequent changes we make to 2.2.1 can merge directly downstream.
 I have not done this in practice but I'm sure some others here have. I'm
 thinking something like this:
 git checkout maven3.0.X
 git merge -s ours origin/maven-2.2.1

 Now of course I want to test this out before we proceed
 {end Theoretical Technical digression for the git-savy}


 Kristian


 2012/10/11 Jason van Zyl ja...@tesla.io

 Say I have the following scenario:

 I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x
 and create some ITs. What's the plan with making sure that we have one
 cohesive set of ITs that we can use across all versions? Just merge
 additions back into every branch? Because we would need to checkout two
 copies in order to be at one branch for the version of Maven you're working
 on and the branch where the ITs are. I understand wanting a rationalized
 fork and with unit tests I understand, but did you forks of large OSS
 projects include ITs like this?

 If that workflow is sorted out it seems fine. I just don't want it to be
 onerous to achieve the discipline of having on coherent set of tests that
 work across all versions of Maven. It's pretty easy to make that consistent
 right now. There's not a huge number of branches so merging additions back
 to each branch is pretty easy. Is that what you had in mind?


 On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

  2012/10/11 Arnaud Héritier aherit...@gmail.com
 
  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 ?
 
 
  If you make any kind of change on a branch (bugfix/feature/whatever) I
  would
  expect to have test

Re: Flipping Maven Core to Git

2012-10-12 Thread Arnaud Héritier

It may still be a good idea to do IT and core-change as two different
commits
If we merge core and ITs I think it will be important to do it (and thus to
ask it to contributors - or we'll need to do it on our side).
I always see few reasons to merge them and find the process a little bit
complex (especially if the committer isn't a Git Guru) but I admit that I
won't bit impacted by this choice as my core contributions were (and will
probably continue to be) near to nothing.
Even if I really support the Git migration I don't want that we decrease
the ability to contribute (it is already a big issue)

Arnaud

On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 Btw; this simplifies the overall workflow to: Check out the oldest version
 you want to support this feature and add your IT + change there. It may
 still be a good idea to do IT and core-change as two different commits

 Kristian


 2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com

  I could not resist, I made this repo and it works well: git clone
  https://github.com/krosenvold/maven-rc.git
 
  It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's
 were
  added at 2.2.1 and merged up to 3.X. Which means we have a straight merge
  based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported
 for
  this mode of operation.
 
  Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand once
  we flip. Also; the pom.xml and the site in this merged repo contain only
  the  core pom (changes from core-its pom.xml and site will have to be
  merged by hand)
 
  Btw: In this repo, you can  checkout trunk (3.X and do git diff
 ...2.2.X
  and see what changes have been added to 2.2.X. Note three ...'s)
 
  Kristian
 
 
  2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com
 
  NIce use case, this is where things get interesting ;) Initially I'll
  just add that this is one of those workflows that might be easier with a
  separate IT repo. This is how the flow would be in a merged single repo:
 
  This workflow has two distinct modes of operation:
 
  1. You always check out the oldest appropriate branch to make the IT. So
  if the IT should apply to 2.2.1 you should check that out. (If we need
 to
  make IT's that go even further back I think it might be easiest to just
  keep the IT's in a separate repo since it gets really hard to actually
  *make* that repo.)
 
  2 A) You are working in a properly branched structure that is
 mergeable
  ; i.e. what we might do between 3.0.X and 3.1 or maybe more
 appropriately
  between 3.X and 4.X.
 
  Make all the changes your heart desires, in any kind of commit sequence
  you prefer. The downstream merge to the subsequent version will fix it
 all.
 
  2 B) You are working i an unmergable branch structure (2.2.1-3.0)
 
  Add the IT as a distinct commit on the 2.2.1 branch, make sure any
  bug-fix you do is done as a separate commit from the IT. When done, you
  will need to check out the 3.0.X branch and cherry pick the commit with
 the
   IT. From 3.0.X on it will merge properly. cherry-picking is a manual
  operation and if you forget it, the IT will be lost on 2.2.1
 
  While this all may seem a bit complex, it's basically the nuts  bolts
 of
  how day-to-day life of a branched workflow functions. When working in
 older
  history, it's usually wise to partition work into well-defined commits,
  because sometimes you might end up cherry-picking only parts of the work
  forward. When you're on trunk you usually don't need to worry about this
  stuff.
 
  {begin Theoretical Technical digression for the git-savy}
  Theoretically we should be able to make a single phoney merge commit
  that re-establishes the mergeability between the 2.2.1 and 3.0.X branch
 so
  that any subsequent changes we make to 2.2.1 can merge directly
 downstream.
  I have not done this in practice but I'm sure some others here have. I'm
  thinking something like this:
  git checkout maven3.0.X
  git merge -s ours origin/maven-2.2.1
 
  Now of course I want to test this out before we proceed
  {end Theoretical Technical digression for the git-savy}
 
 
  Kristian
 
 
  2012/10/11 Jason van Zyl ja...@tesla.io
 
  Say I have the following scenario:
 
  I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x
  and create some ITs. What's the plan with making sure that we have one
  cohesive set of ITs that we can use across all versions? Just merge
  additions back into every branch? Because we would need to checkout two
  copies in order to be at one branch for the version of Maven you're
 working
  on and the branch where the ITs are. I understand wanting a
 rationalized
  fork and with unit tests I understand, but did you forks of large OSS
  projects include ITs like this?
 
  If that workflow is sorted out it seems fine. I just don't want it to
 be
  onerous to achieve the discipline of having on coherent set of tests
 that
  work across all

Re: Flipping Maven Core to Git

2012-10-12 Thread Kristian Rosenvold

My mails came out sort-of in the wrong order, and I'm not sure if I agree
with myself on splitting it changes - core changes.

There is no technical mandate for this, not even a practical one since
establishing mergeability from 2.2.1 - 3.X turned out to be simple.

But as a personal work habit it's smart, because it allows you to change
your mind easily.

Let's say I want to fix MNG- on 3.X. I make an IT from a submitted
sample project and I commit that on the 3.X branch.
Now someone really wants that fixed back on 2.2.1, and it turns out the
backport is real simple. All they need to do is cherry pick the IT and the
core change back to 2.2.1. The IT always cherry-picks cleanly (more or less
by definition due to the way we make IT's), but the core change does not,
so the fix had to be re-applied on 2.2.1. When we merge 2.2.1 back to 3.X,
git will automatically understand that the cherry-picked IT exists in the
future and it won't trouble me with it. If the core change had been part
of the IT commit I would lose this benefit, since the diffs become
different (lol).

(A diff that already exists in the history won't be reapplied, which is why
it's so good to move *complete* commits backwards in time).

Kristian


2012/10/12 Arnaud Héritier aherit...@gmail.com

 It may still be a good idea to do IT and core-change as two different
 commits
 If we merge core and ITs I think it will be important to do it (and thus to
 ask it to contributors - or we'll need to do it on our side).
 I always see few reasons to merge them and find the process a little bit
 complex (especially if the committer isn't a Git Guru) but I admit that I
 won't bit impacted by this choice as my core contributions were (and will
 probably continue to be) near to nothing.
 Even if I really support the Git migration I don't want that we decrease
 the ability to contribute (it is already a big issue)

 Arnaud

 On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

  Btw; this simplifies the overall workflow to: Check out the oldest
 version
  you want to support this feature and add your IT + change there. It may
  still be a good idea to do IT and core-change as two different commits
 
  Kristian
 
 
  2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com
 
   I could not resist, I made this repo and it works well: git clone
   https://github.com/krosenvold/maven-rc.git
  
   It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's
  were
   added at 2.2.1 and merged up to 3.X. Which means we have a straight
 merge
   based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported
  for
   this mode of operation.
  
   Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand
 once
   we flip. Also; the pom.xml and the site in this merged repo contain
 only
   the  core pom (changes from core-its pom.xml and site will have to be
   merged by hand)
  
   Btw: In this repo, you can  checkout trunk (3.X and do git diff
  ...2.2.X
   and see what changes have been added to 2.2.X. Note three ...'s)
  
   Kristian
  
  
   2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com
  
   NIce use case, this is where things get interesting ;) Initially I'll
   just add that this is one of those workflows that might be easier
 with a
   separate IT repo. This is how the flow would be in a merged single
 repo:
  
   This workflow has two distinct modes of operation:
  
   1. You always check out the oldest appropriate branch to make the IT.
 So
   if the IT should apply to 2.2.1 you should check that out. (If we need
  to
   make IT's that go even further back I think it might be easiest to
 just
   keep the IT's in a separate repo since it gets really hard to actually
   *make* that repo.)
  
   2 A) You are working in a properly branched structure that is
  mergeable
   ; i.e. what we might do between 3.0.X and 3.1 or maybe more
  appropriately
   between 3.X and 4.X.
  
   Make all the changes your heart desires, in any kind of commit
 sequence
   you prefer. The downstream merge to the subsequent version will fix it
  all.
  
   2 B) You are working i an unmergable branch structure (2.2.1-3.0)
  
   Add the IT as a distinct commit on the 2.2.1 branch, make sure any
   bug-fix you do is done as a separate commit from the IT. When done,
 you
   will need to check out the 3.0.X branch and cherry pick the commit
 with
  the
IT. From 3.0.X on it will merge properly. cherry-picking is a manual
   operation and if you forget it, the IT will be lost on 2.2.1
  
   While this all may seem a bit complex, it's basically the nuts  bolts
  of
   how day-to-day life of a branched workflow functions. When working in
  older
   history, it's usually wise to partition work into well-defined
 commits,
   because sometimes you might end up cherry-picking only parts of the
 work
   forward. When you're on trunk you usually don't need to worry about
 this
   stuff.
  
   {begin Theoretical

Re: Flipping Maven Core to Git

2012-10-12 Thread Igor Fedorenko


Although I understand we can make the merged repository work, at least
with some discipline from developers, I think merged source repository
makes changes to the integration tests perceptually okay, which imho
is rarely the case. I actually maintained fork of maven ITs for
awhile, and personally I did not find it too much trouble. At least as
long as I was only adding new ITs, not changing existing ones.

Just my 2c.

--
Regards,
Igor

On 12-10-12 3:47 AM, Kristian Rosenvold wrote:

My mails came out sort-of in the wrong order, and I'm not sure if I agree
with myself on splitting it changes - core changes.

There is no technical mandate for this, not even a practical one since
establishing mergeability from 2.2.1 - 3.X turned out to be simple.

But as a personal work habit it's smart, because it allows you to change
your mind easily.

Let's say I want to fix MNG- on 3.X. I make an IT from a submitted
sample project and I commit that on the 3.X branch.
Now someone really wants that fixed back on 2.2.1, and it turns out the
backport is real simple. All they need to do is cherry pick the IT and the
core change back to 2.2.1. The IT always cherry-picks cleanly (more or less
by definition due to the way we make IT's), but the core change does not,
so the fix had to be re-applied on 2.2.1. When we merge 2.2.1 back to 3.X,
git will automatically understand that the cherry-picked IT exists in the
future and it won't trouble me with it. If the core change had been part
of the IT commit I would lose this benefit, since the diffs become
different (lol).

(A diff that already exists in the history won't be reapplied, which is why
it's so good to move *complete* commits backwards in time).

Kristian


2012/10/12 Arnaud Héritier aherit...@gmail.com


It may still be a good idea to do IT and core-change as two different
commits
If we merge core and ITs I think it will be important to do it (and thus to
ask it to contributors - or we'll need to do it on our side).
I always see few reasons to merge them and find the process a little bit
complex (especially if the committer isn't a Git Guru) but I admit that I
won't bit impacted by this choice as my core contributions were (and will
probably continue to be) near to nothing.
Even if I really support the Git migration I don't want that we decrease
the ability to contribute (it is already a big issue)

Arnaud

On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:


Btw; this simplifies the overall workflow to: Check out the oldest

version

you want to support this feature and add your IT + change there. It may
still be a good idea to do IT and core-change as two different commits

Kristian


2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com


I could not resist, I made this repo and it works well: git clone
https://github.com/krosenvold/maven-rc.git

It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's

were

added at 2.2.1 and merged up to 3.X. Which means we have a straight

merge

based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported

for

this mode of operation.

Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand

once

we flip. Also; the pom.xml and the site in this merged repo contain

only

the  core pom (changes from core-its pom.xml and site will have to be
merged by hand)

Btw: In this repo, you can  checkout trunk (3.X and do git diff

...2.2.X

and see what changes have been added to 2.2.X. Note three ...'s)

Kristian


2012/10/12 Kristian Rosenvold kristian.rosenv...@gmail.com


NIce use case, this is where things get interesting ;) Initially I'll
just add that this is one of those workflows that might be easier

with a

separate IT repo. This is how the flow would be in a merged single

repo:


This workflow has two distinct modes of operation:

1. You always check out the oldest appropriate branch to make the IT.

So

if the IT should apply to 2.2.1 you should check that out. (If we need

to

make IT's that go even further back I think it might be easiest to

just

keep the IT's in a separate repo since it gets really hard to actually
*make* that repo.)

2 A) You are working in a properly branched structure that is

mergeable

; i.e. what we might do between 3.0.X and 3.1 or maybe more

appropriately

between 3.X and 4.X.

Make all the changes your heart desires, in any kind of commit

sequence

you prefer. The downstream merge to the subsequent version will fix it

all.


2 B) You are working i an unmergable branch structure (2.2.1-3.0)

Add the IT as a distinct commit on the 2.2.1 branch, make sure any
bug-fix you do is done as a separate commit from the IT. When done,

you

will need to check out the 3.0.X branch and cherry pick the commit

with

the

  IT. From 3.0.X on it will merge properly. cherry-picking is a manual
operation and if you forget it, the IT will be lost on 2.2.1

While this all may seem a bit complex, it's basically the nuts  bolts

of

Re: Flipping Maven Core to Git

2012-10-11 Thread Anders Hammar

So, what is the solution to fixing the ITs that depend on an empty
folder? Put some dummy file there? But then the folder will not be
empty...

/Anders

On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without flipping 
 the integration tests.

 It might actually be better to not move both of those at the same time.

 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and work 
 on the core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is not 
 worth knowing.

 -- Alan Perlis

 -
 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

 Thanks,

 Jason

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

 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition






 -
 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

Re: Flipping Maven Core to Git

Jason ran the tests based off the git repo and they were fine. There
is no problem (I've had my fair share of troubles with the core it's
so it's probably been a problem between chair and keyboard).

Unless someone objects I'll file a INFRA jira to port m3-core + IT's
sometime later today.

Kristian

2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

 /Anders

 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without 
 flipping the integration tests.

 It might actually be better to not move both of those at the same time.

 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and 
 work on the core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is 
 not worth knowing.

 -- Alan Perlis

 -
 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

 Thanks,

 Jason

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

 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition






 -
 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

Re: Flipping Maven Core to Git

2012-10-11 Thread Mark Struberg

Kristian, wait a bit.

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.

Also for a maven-core release it isn't a problem if the ITs get tagged. I 
actually would even really appreciate that fact!

LieGrue,
strub




- Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Thursday, October 11, 2012 8:35 AM
 Subject: Re: Flipping Maven Core to Git
 
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
  So, what is the solution to fixing the ITs that depend on an empty
  folder? Put some dummy file there? But then the folder will not be
  empty...
 
  /Anders
 
  On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
  kristian.rosenv...@zenior.no wrote:
  So you're going to be working on the core without touching the 
 it's?
 
  Seriously, this discussion is going nowhere. We move both and someone
  speeds 45 minutes fixing the it's.
 
  Kristian
 
  Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
  I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
  It might actually be better to not move both of those at the same 
 time.
 
  On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
  It's just two simple projects that have some very simple 
 fixes that
  need to be done (git does not preserve empty directories and I 
 seem to
  recall that a couple of it's failed due to this).
 
  I say we do the 3.1 release off git ;) Move both.
 
  Kristian
 
 
  2012/10/10 Anders Hammar and...@hammar.net:
  I see no reason they need to be migrate at the same time.
 
  /Anders
 
  On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl 
 ja...@tesla.io wrote:
  So in chatting with Kristian it appears the the core is 
 ready to flip, while the integration tests need some work. Can we flip the 
 core 
 and work on the core integrations test afterward?
 
  Thanks,
 
  Jason
 
 
 --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
 
 -
 
  A language that doesn’t affect the way you think about 
 programming is not worth knowing.
 
  -- Alan Perlis
 
 
 -
  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
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Our achievements speak for themselves. What we have to keep track
  of are our failures, discouragements and doubts. We tend to forget
  the past difficulties, the many false starts, and the painful
  groping. We see our past achievements as the end result of a
  clean forward thrust, and our present difficulties as
  signs of decline and decay.
 
  -- Eric Hoffer, Reflections on the Human Condition
 
 
 
 
 
 
  -
  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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Flipping Maven Core to Git

2012/10/11 Mark Struberg strub...@yahoo.de:
 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.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Flipping Maven Core to Git

2012-10-11 Thread Stephen Connolly

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:;

Re: Flipping Maven Core to Git

$ ls -1b maven-3/
README.bootstrap.txt
README.md
README.txt
apache-maven
build.xml
doap_Maven.rdf
maven-aether-provider
maven-ant-tasks-2.1.1.jar
maven-artifact
maven-compat
maven-core
maven-embedder
maven-model
maven-model-builder
maven-plugin-api
maven-repository-metadata
maven-settings
maven-settings-builder
maven.iml
pom.xml
src
target

$ ls -1b core-its/
README
core-it-suite
core-it-support
pom.xml
src


I really think they could just end up being side by side (without root
folders for each)  and merge the root pom by hand, adding the two
core-it-* modules and setting up a run-its profile like the rest of
our projects.

I think the argument for doing this is that it increases the focus on
the existence of the core it suite. I really see no significant
downsides ?

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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.orgjavascript:;
 
 




-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: Flipping Maven Core to Git

2012-10-11 Thread Mark Struberg

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?


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.orgjavascript:;
  
  
 
 
 
 
 -- 
 -
 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

Re: Flipping Maven Core to Git

Initially I thought Arnaud's argument for being able to run against a
different maven version was a killer; we needed to keep them
separate.

After giving it some more thought I'm not sure it's a good argument,
we don't lose the ability to do so if we merge the trees (it's just
one of many possible flags to use when running the its, all available
in the docs)

So I'm still marginally in favour of merging the trees, if only to
increas focus on the IT's.

Kristian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Flipping Maven Core to Git

As far as it is always possible (and easy) to do (and to setup on CI side
as it will be the first one to run them) I'll follow you.

Arnaud

On Thu, Oct 11, 2012 at 9:56 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 Initially I thought Arnaud's argument for being able to run against a
 different maven version was a killer; we needed to keep them
 separate.

 After giving it some more thought I'm not sure it's a good argument,
 we don't lose the ability to do so if we merge the trees (it's just
 one of many possible flags to use when running the its, all available
 in the docs)

 So I'm still marginally in favour of merging the trees, if only to
 increas focus on the IT's.

 Kristian

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: Flipping Maven Core to Git

2012-10-11 Thread Anders Hammar

Are we then also saying that we merge the maven-2 source into this git
repo as well (if we convert that to git)?

/Anders

On Thu, Oct 11, 2012 at 10:01 AM, Arnaud Héritier aherit...@gmail.com wrote:
 As far as it is always possible (and easy) to do (and to setup on CI side
 as it will be the first one to run them) I'll follow you.

 Arnaud

 On Thu, Oct 11, 2012 at 9:56 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 Initially I thought Arnaud's argument for being able to run against a
 different maven version was a killer; we needed to keep them
 separate.

 After giving it some more thought I'm not sure it's a good argument,
 we don't lose the ability to do so if we merge the trees (it's just
 one of many possible flags to use when running the its, all available
 in the docs)

 So I'm still marginally in favour of merging the trees, if only to
 increas focus on the IT's.

 Kristian

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 -
 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

Re: Flipping Maven Core to Git

Why too much rush ?
Perso, I will be happy to see similar rush on writing test/doc the
stuff committed 1,5 month ago !.(despite a number of ping)
AFAIK (maybe I miss something) using @Inject is not so trivial because
we need to generate the sisu index.
Which is very similar to what we do currently with plexus plugins
which generate metadata.
So what is the added value for users or plugin developers (except
using the last à la mode @Inject).
I will be happy to hear the added values (performance ? etc .. ?)

regarding last commit regarding logs in trunk, I tested that and the
artifact transfer progress(download/upload) is now (IMHO) very crappy
!!

[INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
[INFO] 
[INFO] Downloading:
https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
[INFO] 4/16 KB
[INFO] 8/16 KB
[INFO] 12/16 KB
[INFO] 16/16 KB
[INFO] 16/16 KB
[INFO]
[INFO] Downloaded:
https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 9.2 KB/sec)
[INFO] Downloading:
https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
[INFO] 4/47 KB
[INFO] 8/47 KB
[INFO] 12/47 KB
[INFO] 16/47 KB
[INFO] 20/47 KB
[INFO] 24/47 KB
[INFO] 28/47 KB
[INFO] 31/47 KB
[INFO] 35/47 KB
[INFO] 38/47 KB
[INFO] 42/47 KB
[INFO] 46/47 KB
[INFO] 47/47 KB
[INFO]
[INFO] Downloaded:
https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
(47 KB at 45.8 KB/sec)

Sorry I didn't investigate more on the reason.

2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).

 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.

 Kristian

 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

 /Anders

 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without 
 flipping the integration tests.

 It might actually be better to not move both of those at the same time.

 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and 
 work on the core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is 
 not worth knowing.

 -- Alan Perlis

 -
 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

 Thanks,

 Jason

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

 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: Flipping Maven Core to Git

2012-10-11 Thread Mark Struberg

we need to revert/fix the log commit anyway for now as we don't yet have the 
classloader isolation code.

LieGrue,
strub




- Original Message -
 From: Olivier Lamy ol...@apache.org
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Thursday, October 11, 2012 10:19 AM
 Subject: Re: Flipping Maven Core to Git
 
 Why too much rush ?
 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)
 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 
 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
  Jason ran the tests based off the git repo and they were fine. There
  is no problem (I've had my fair share of troubles with the core 
 it's
  so it's probably been a problem between chair and keyboard).
 
  Unless someone objects I'll file a INFRA jira to port m3-core + 
 IT's
  sometime later today.
 
  Kristian
 
  2012/10/11 Anders Hammar and...@hammar.net:
  So, what is the solution to fixing the ITs that depend on an empty
  folder? Put some dummy file there? But then the folder will not be
  empty...
 
  /Anders
 
  On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
  kristian.rosenv...@zenior.no wrote:
  So you're going to be working on the core without touching the 
 it's?
 
  Seriously, this discussion is going nowhere. We move both and 
 someone
  speeds 45 minutes fixing the it's.
 
  Kristian
 
  Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl 
 ja...@tesla.io:
 
  I think we can flip the core, we can still release the core 
 without flipping the integration tests.
 
  It might actually be better to not move both of those at the 
 same time.
 
  On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
  It's just two simple projects that have some very 
 simple fixes that
  need to be done (git does not preserve empty directories 
 and I seem to
  recall that a couple of it's failed due to this).
 
  I say we do the 3.1 release off git ;) Move both.
 
  Kristian
 
 
  2012/10/10 Anders Hammar and...@hammar.net:
  I see no reason they need to be migrate at the same 
 time.
 
  /Anders
 
  On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl 
 ja...@tesla.io wrote:
  So in chatting with Kristian it appears the the 
 core is ready to flip, while the integration tests need some work. Can we 
 flip 
 the core and work on the core integrations test afterward?
 
  Thanks,
 
  Jason
 
 
 --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
 
 -
 
  A language that doesn’t affect the way you think 
 about programming is not worth knowing.
 
  -- Alan Perlis
 
 
 -
  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
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache

Re: Flipping Maven Core to Git


On Oct 11, 2012, at 12:18 AM, Kristian Rosenvold kristian.rosenv...@zenior.no 
wrote:

 So you're going to be working on the core without touching the it's?
 

That's not what I said. It is possible the run the ITs while in subversion 
while the core is in Git.

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without flipping 
 the integration tests.
 
 It might actually be better to not move both of those at the same time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).
 
 I say we do the 3.1 release off git ;) Move both.
 
 Kristian
 
 
 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.
 
 /Anders
 
 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and work 
 on the core integrations test afterward?
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 A language that doesn’t affect the way you think about programming is not 
 worth knowing.
 
 -- Alan Perlis
 
 -
 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
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.
 
 -- Eric Hoffer, Reflections on the Human Condition
 
 
 
 
 
 
 -
 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
-

We know what we are, but know not what we may be.

  -- Shakespeare

Re: Flipping Maven Core to Git


On Oct 11, 2012, at 2:41 AM, Mark Struberg strub...@yahoo.de wrote:

 Kristian, wait a bit.
 
 What if we first merge the 2 repos into 1 git repo?
 

-1

They are separate for the specific reason that the body of ITs be independent 
from the core and easily run against multiple versions of Maven.

 Imo maven-core and the ITs must fit together! Having the ITs in a separate 
 repo will make people forget about them.
 

No one has ever forgotten about them since they were first written. Why is that 
a concern?

 Also for a maven-core release it isn't a problem if the ITs get tagged. I 
 actually would even really appreciate that fact!
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Kristian Rosenvold kristian.rosenv...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Thursday, October 11, 2012 8:35 AM
 Subject: Re: Flipping Maven Core to Git
 
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...
 
 /Anders
 
 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the 
 it's?
 
 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
 It might actually be better to not move both of those at the same 
 time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple 
 fixes that
 need to be done (git does not preserve empty directories and I 
 seem to
 recall that a couple of it's failed due to this).
 
 I say we do the 3.1 release off git ;) Move both.
 
 Kristian
 
 
 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.
 
 /Anders
 
 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl 
 ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is 
 ready to flip, while the integration tests need some work. Can we flip the 
 core 
 and work on the core integrations test afterward?
 
 Thanks,
 
 Jason
 
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 
 -
 
 A language that doesn’t affect the way you think about 
 programming is not worth knowing.
 
 -- Alan Perlis
 
 
 -
 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
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.
 
 -- Eric Hoffer, Reflections on the Human Condition
 
 
 
 
 
 
 -
 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
 
 
 -
 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

Re: Flipping Maven Core to Git

I just merged the maven-2 and the maven-3 git repo back together using
something like this:

git clone http://git.apache.org/maven-3.git
cd maven-3
git remote add m2 http://git.apache.org/maven-2.git
git fetch m2

And it works perfectly; you can even run git merge-base maven-2.2.x
trunk to find the branch point ;)

They share common history in the existing git clones. If we move the
maven-3 repo I think we might call it maven and just re-add the
maven-2 history.

Kristian



2012/10/11 Anders Hammar and...@hammar.net:
 Are we then also saying that we merge the maven-2 source into this git
 repo as well (if we convert that to git)?

 /Anders

 On Thu, Oct 11, 2012 at 10:01 AM, Arnaud Héritier aherit...@gmail.com wrote:
 As far as it is always possible (and easy) to do (and to setup on CI side
 as it will be the first one to run them) I'll follow you.

 Arnaud

 On Thu, Oct 11, 2012 at 9:56 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 Initially I thought Arnaud's argument for being able to run against a
 different maven version was a killer; we needed to keep them
 separate.

 After giving it some more thought I'm not sure it's a good argument,
 we don't lose the ability to do so if we merge the trees (it's just
 one of many possible flags to use when running the its, all available
 in the docs)

 So I'm still marginally in favour of merging the trees, if only to
 increas focus on the IT's.

 Kristian

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 -
 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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Flipping Maven Core to Git


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.orgjavascript:;
 
 
 
 
 
 
 -- 
 -
 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

Re: Flipping Maven Core to Git

I would prefer to have one maven-core git repo with various branches as we
don't have the SVN constraint that justified to have several entry points
instead of branches.

On Thu, Oct 11, 2012 at 10:58 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 I just merged the maven-2 and the maven-3 git repo back together using
 something like this:

 git clone http://git.apache.org/maven-3.git
 cd maven-3
 git remote add m2 http://git.apache.org/maven-2.git
 git fetch m2

 And it works perfectly; you can even run git merge-base maven-2.2.x
 trunk to find the branch point ;)

 They share common history in the existing git clones. If we move the
 maven-3 repo I think we might call it maven and just re-add the
 maven-2 history.

 Kristian



 2012/10/11 Anders Hammar and...@hammar.net:
  Are we then also saying that we merge the maven-2 source into this git
  repo as well (if we convert that to git)?
 
  /Anders
 
  On Thu, Oct 11, 2012 at 10:01 AM, Arnaud Héritier aherit...@gmail.com
 wrote:
  As far as it is always possible (and easy) to do (and to setup on CI
 side
  as it will be the first one to run them) I'll follow you.
 
  Arnaud
 
  On Thu, Oct 11, 2012 at 9:56 AM, Kristian Rosenvold 
  kristian.rosenv...@gmail.com wrote:
 
  Initially I thought Arnaud's argument for being able to run against a
  different maven version was a killer; we needed to keep them
  separate.
 
  After giving it some more thought I'm not sure it's a good argument,
  we don't lose the ability to do so if we merge the trees (it's just
  one of many possible flags to use when running the its, all available
  in the docs)
 
  So I'm still marginally in favour of merging the trees, if only to
  increas focus on the IT's.
 
  Kristian
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  -
  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
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: Flipping Maven Core to Git


On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

 Why too much rush ?

I just find it more convenient to have everything in Git. Makes the testing 
cycle more pleasant and the git svn workflow isn't something I personally 
enjoy. I'm working on the core and it's nothing more than a preference.

 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)

I'll answer these in another post. With the documentation, that will be easier.

 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 

I'm not sure technically what very crappy means. You mean the way it visually 
looks?

 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...
 
 /Anders
 
 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?
 
 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
 It might actually be better to not move both of those at the same time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).
 
 I say we do the 3.1 release off git ;) Move both.
 
 Kristian
 
 
 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.
 
 /Anders
 
 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and 
 work on the core integrations test afterward?
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 A language that doesn’t affect the way you think about programming is 
 not worth knowing.
 
 -- Alan Perlis
 
 -
 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
 
 Thanks,
 
 Jason
 
 --
 Jason van

Re: Flipping Maven Core to Git

2012/10/11 Jason van Zyl ja...@tesla.io:

 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

 Why too much rush ?

 I just find it more convenient to have everything in Git. Makes the testing 
 cycle more pleasant and the git svn workflow isn't something I personally 
 enjoy. I'm working on the core and it's nothing more than a preference.

 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)

 I'll answer these in another post. With the documentation, that will be 
 easier.


 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!


 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
Yup visible changes for users will be a tons of lines in the console.
Maybe it's just matter of log layout to configure (As I didn't have a
look I don't know)

Something else when building core with ant bootstrap (sure not really
important :-)):

process-classes:
 [echo] Using plexus version 1.5.5
 [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
 [java] SLF4J: See
http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.


 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)

 Sorry I didn't investigate more on the reason.

 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).

 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.

 Kristian

 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

 /Anders

 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without 
 flipping the integration tests.

 It might actually be better to not move both of those at the same time.

 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to 
 flip, while the integration tests need some work. Can we flip the 
 core and work on the core integrations test afterward?

 Thanks,

 Jason

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

 A language

Re: Flipping Maven Core to Git

I can look at both of those, maybe we can figure something out in the simple 
implementation to make it look better. Ant thing looks easy enough to fix.

On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:
 
 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:
 
 Why too much rush ?
 
 I just find it more convenient to have everything in Git. Makes the testing 
 cycle more pleasant and the git svn workflow isn't something I personally 
 enjoy. I'm working on the core and it's nothing more than a preference.
 
 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)
 
 I'll answer these in another post. With the documentation, that will be 
 easier.
 
 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 
 
 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)
 
 Something else when building core with ant bootstrap (sure not really
 important :-)):
 
 process-classes:
 [echo] Using plexus version 1.5.5
 [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
 [java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 
 
 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...
 
 /Anders
 
 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?
 
 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
 It might actually be better to not move both of those at the same time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).
 
 I say we do the 3.1 release off git ;) Move both.
 
 Kristian
 
 
 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.
 
 /Anders
 
 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to 
 flip, while the integration tests need some work. Can we flip the 
 core and work on the core

Re: Flipping Maven Core to Git

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.orgjavascript:;






 --
 -
 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

Re: Flipping Maven Core to Git

2012-10-11 Thread Stephen Connolly

OK, you have won me over.

Lets keep them in one repo.

We can do some work down the line to make the ITs a separately releasable
bundle and that way make it easy to run the latest ITs against older
versions and vice versa

better to get the git repo right from the start rather than rewrite history
to get a proper history.

On 11 October 2012 10:40, Kristian Rosenvold
kristian.rosenv...@gmail.comwrote:

 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

Re: Flipping Maven Core to Git

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 kristian.rosenv...@gmail.com 
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 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.orgjavascript:;
 
 
 
 
 
 
 --
 -
 Arnaud Héritier
 06-89-76-64-24
 http://aheritier.net
 Mail/GTalk: aherit...@gmail.com
 Twitter/Skype : aheritier

RE: Flipping Maven Core to Git

2012-10-11 Thread Martin Gainty

Hi Oliverwhat are the advantages of moving from tried and true (works 
everytime) workhorse of svn to git version control ?
thanks, From: ol...@apache.org
 Date: Thu, 11 Oct 2012 11:31:04 +0200
 Subject: Re: Flipping Maven Core to Git
 To: dev@maven.apache.

 2012/10/11 Jason van Zyl ja...@tesla.io:

  On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

  Why too much rush ?

  I just find it more convenient to have everything in Git. Makes the testing 
  cycle more pleasant and the git svn workflow isn't something I personally 
  enjoy. I'm working on the core and it's nothing more than a preference.

  Perso, I will be happy to see similar rush on writing test/doc the
  stuff committed 1,5 month ago !.(despite a number of ping)
  AFAIK (maybe I miss something) using @Inject is not so trivial because
  we need to generate the sisu index.
  Which is very similar to what we do currently with plexus plugins
  which generate metadata.
  So what is the added value for users or plugin developers (except
  using the last à la mode @Inject).
  I will be happy to hear the added values (performance ? etc .. ?)

  I'll answer these in another post. With the documentation, that will be 
  easier.

  regarding last commit regarding logs in trunk, I tested that and the
  artifact transfer progress(download/upload) is now (IMHO) very crappy
  !!

  I'm not sure technically what very crappy means. You mean the way it 
  visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)

 Something else when building core with ant bootstrap (sure not really
 important :-)):

 process-classes:
  [echo] Using plexus version 1.5.5
  [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
  [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
  [java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.

  [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
  [INFO] 

  [INFO] Downloading:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  [INFO] 4/16 KB
  [INFO] 8/16 KB
  [INFO] 12/16 KB
  [INFO] 16/16 KB
  [INFO] 16/16 KB
  [INFO]
  [INFO] Downloaded:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 9.2 KB/sec)
  [INFO] Downloading:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
  [INFO] 4/47 KB
  [INFO] 8/47 KB
  [INFO] 12/47 KB
  [INFO] 16/47 KB
  [INFO] 20/47 KB
  [INFO] 24/47 KB
  [INFO] 28/47 KB
  [INFO] 31/47 KB
  [INFO] 35/47 KB
  [INFO] 38/47 KB
  [INFO] 42/47 KB
  [INFO] 46/47 KB
  [INFO] 47/47 KB
  [INFO]
  [INFO] Downloaded:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
  (47 KB at 45.8 KB/sec)

  Sorry I didn't investigate more on the reason.

  2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
  Jason ran the tests based off the git repo and they were fine. There
  is no problem (I've had my fair share of troubles with the core it's
  so it's probably been a problem between chair and keyboard).

  Unless someone objects I'll file a INFRA jira to port m3-core + IT's
  sometime later today.

  Kristian

  2012/10/11 Anders Hammar and...@hammar.net:
  So, what is the solution to fixing the ITs that depend on an empty
  folder? Put some dummy file there? But then the folder will not be
  empty...

  /Anders

  On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
  kristian.rosenv...@zenior.no wrote:
  So you're going to be working on the core without touching the it's?

  Seriously, this discussion is going nowhere. We move both and someone
  speeds 45 minutes fixing the it's.

  Kristian

  Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

  I think we can flip the core, we can still release the core without 
  flipping the integration tests.

  It might actually be better to not move both of those at the same time.

  On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
  kristian.rosenv...@gmail.com wrote:

  It's just two simple projects that have some very simple fixes that
  need to be done (git does not preserve empty directories and I seem to
  recall that a couple of it's failed due to this).

  I say we do the 3.1 release off git ;) Move both.

  Kristian

  2012/10/10 Anders Hammar and...@hammar.net:
  I see no reason they need to be migrate at the same time.

  /Anders

  On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io 
  wrote:
  So in chatting with Kristian

Re: Flipping Maven Core to Git

2012-10-11 Thread Benson Margulies

On Thu, Oct 11, 2012 at 7:43 AM, Martin Gainty mgai...@hotmail.com wrote:

 Hi Oliverwhat are the advantages of moving from tried and true (works 
 everytime) workhorse of svn to git version control ?

We already discussed and voted this question. let's not do it again.

 thanks, From: ol...@apache.org
 Date: Thu, 11 Oct 2012 11:31:04 +0200
 Subject: Re: Flipping Maven Core to Git
 To: dev@maven.apache.

 2012/10/11 Jason van Zyl ja...@tesla.io:

  On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

  Why too much rush ?

  I just find it more convenient to have everything in Git. Makes the 
  testing cycle more pleasant and the git svn workflow isn't something I 
  personally enjoy. I'm working on the core and it's nothing more than a 
  preference.

  Perso, I will be happy to see similar rush on writing test/doc the
  stuff committed 1,5 month ago !.(despite a number of ping)
  AFAIK (maybe I miss something) using @Inject is not so trivial because
  we need to generate the sisu index.
  Which is very similar to what we do currently with plexus plugins
  which generate metadata.
  So what is the added value for users or plugin developers (except
  using the last à la mode @Inject).
  I will be happy to hear the added values (performance ? etc .. ?)

  I'll answer these in another post. With the documentation, that will be 
  easier.

  regarding last commit regarding logs in trunk, I tested that and the
  artifact transfer progress(download/upload) is now (IMHO) very crappy
  !!

  I'm not sure technically what very crappy means. You mean the way it 
  visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)

 Something else when building core with ant bootstrap (sure not really
 important :-)):

 process-classes:
  [echo] Using plexus version 1.5.5
  [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
  [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
  [java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.

  [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
  [INFO] 

  [INFO] Downloading:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  [INFO] 4/16 KB
  [INFO] 8/16 KB
  [INFO] 12/16 KB
  [INFO] 16/16 KB
  [INFO] 16/16 KB
  [INFO]
  [INFO] Downloaded:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 9.2 KB/sec)
  [INFO] Downloading:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
  [INFO] 4/47 KB
  [INFO] 8/47 KB
  [INFO] 12/47 KB
  [INFO] 16/47 KB
  [INFO] 20/47 KB
  [INFO] 24/47 KB
  [INFO] 28/47 KB
  [INFO] 31/47 KB
  [INFO] 35/47 KB
  [INFO] 38/47 KB
  [INFO] 42/47 KB
  [INFO] 46/47 KB
  [INFO] 47/47 KB
  [INFO]
  [INFO] Downloaded:
  https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
  (47 KB at 45.8 KB/sec)

  Sorry I didn't investigate more on the reason.

  2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
  Jason ran the tests based off the git repo and they were fine. There
  is no problem (I've had my fair share of troubles with the core it's
  so it's probably been a problem between chair and keyboard).

  Unless someone objects I'll file a INFRA jira to port m3-core + IT's
  sometime later today.

  Kristian

  2012/10/11 Anders Hammar and...@hammar.net:
  So, what is the solution to fixing the ITs that depend on an empty
  folder? Put some dummy file there? But then the folder will not be
  empty...

  /Anders

  On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
  kristian.rosenv...@zenior.no wrote:
  So you're going to be working on the core without touching the it's?

  Seriously, this discussion is going nowhere. We move both and someone
  speeds 45 minutes fixing the it's.

  Kristian

  Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

  I think we can flip the core, we can still release the core without 
  flipping the integration tests.

  It might actually be better to not move both of those at the same 
  time.

  On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
  kristian.rosenv...@gmail.com wrote:

  It's just two simple projects that have some very simple fixes that
  need to be done (git does not preserve empty directories and I seem 
  to
  recall that a couple of it's failed due to this).

  I say we do the 3.1 release off git ;) Move both.

  Kristian

  2012/10/10 Anders Hammar and...@hammar.net:
  I see no reason they need

Re: Flipping Maven Core to Git

2012/10/11 Jason van Zyl ja...@tesla.io:
 I can look at both of those, maybe we can figure something out in the simple 
 implementation to make it look better. Ant thing looks easy enough to fix.
nice.
BTW some its are failing too:
https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/lastCompletedBuild/testReport/


 On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:

 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

 Why too much rush ?

 I just find it more convenient to have everything in Git. Makes the testing 
 cycle more pleasant and the git svn workflow isn't something I personally 
 enjoy. I'm working on the core and it's nothing more than a preference.

 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)

 I'll answer these in another post. With the documentation, that will be 
 easier.


 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!


 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)

 Something else when building core with ant bootstrap (sure not really
 important :-)):

 process-classes:
 [echo] Using plexus version 1.5.5
 [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
 [java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.


 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)

 Sorry I didn't investigate more on the reason.

 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).

 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.

 Kristian

 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

 /Anders

 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without 
 flipping the integration tests.

 It might actually be better to not move both of those at the same time.

 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io 
 wrote:
 So in

Re: Flipping Maven Core to Git

Yup, the ITs don't seem to run when changes are made. Are they manually 
triggered? I waited last night for a while but nothing was happening.

On Oct 11, 2012, at 8:30 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:
 I can look at both of those, maybe we can figure something out in the simple 
 implementation to make it look better. Ant thing looks easy enough to fix.
 nice.
 BTW some its are failing too:
 https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/lastCompletedBuild/testReport/
 
 
 On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:
 
 2012/10/11 Jason van Zyl ja...@tesla.io:
 
 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:
 
 Why too much rush ?
 
 I just find it more convenient to have everything in Git. Makes the 
 testing cycle more pleasant and the git svn workflow isn't something I 
 personally enjoy. I'm working on the core and it's nothing more than a 
 preference.
 
 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)
 
 I'll answer these in another post. With the documentation, that will be 
 easier.
 
 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 
 
 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)
 
 Something else when building core with ant bootstrap (sure not really
 important :-)):
 
 process-classes:
[echo] Using plexus version 1.5.5
[java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
[java] SLF4J: Defaulting to no-operation (NOP) logger implementation
[java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 
 
 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...
 
 /Anders
 
 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?
 
 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
 It might actually be better to not move both of those at the same 
 time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem 
 to
 recall that a couple of it's failed due to this).
 
 I say we

Re: Flipping Maven Core to Git

Is there actually a MAC in the test grid as I see it's grayed out and hasn't 
run in over a year? Any particular reason?

On Oct 11, 2012, at 8:30 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:
 I can look at both of those, maybe we can figure something out in the simple 
 implementation to make it look better. Ant thing looks easy enough to fix.
 nice.
 BTW some its are failing too:
 https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/lastCompletedBuild/testReport/
 
 
 On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:
 
 2012/10/11 Jason van Zyl ja...@tesla.io:
 
 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:
 
 Why too much rush ?
 
 I just find it more convenient to have everything in Git. Makes the 
 testing cycle more pleasant and the git svn workflow isn't something I 
 personally enjoy. I'm working on the core and it's nothing more than a 
 preference.
 
 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)
 
 I'll answer these in another post. With the documentation, that will be 
 easier.
 
 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 
 
 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)
 
 Something else when building core with ant bootstrap (sure not really
 important :-)):
 
 process-classes:
[echo] Using plexus version 1.5.5
[java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
[java] SLF4J: Defaulting to no-operation (NOP) logger implementation
[java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 
 
 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...
 
 /Anders
 
 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?
 
 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.
 
 Kristian
 
 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:
 
 I think we can flip the core, we can still release the core without 
 flipping the integration tests.
 
 It might actually be better to not move both of those at the same 
 time.
 
 On Oct 10, 2012, at 2:36 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem 
 to
 recall that a couple of it's failed due to this).
 
 I say we do the 3.1 release off

Re: Flipping Maven Core to Git

2012/10/11 Jason van Zyl ja...@tesla.io:
 Yup, the ITs don't seem to run when changes are made. Are they manually 
 triggered? I waited last night for a while but nothing was happening.
there are triggered by changes in
http://svn.apache.org/repos/asf/maven/maven-3/trunk or in core its
source tree.
If I correctly read here
https://builds.apache.org/view/M-R/view/Maven/ they runed around 13H
ago (depending on nodes some are not used a lot by other asf projects)
13H ago is very similar to your last commit time


 On Oct 11, 2012, at 8:30 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:
 I can look at both of those, maybe we can figure something out in the 
 simple implementation to make it look better. Ant thing looks easy enough 
 to fix.
 nice.
 BTW some its are failing too:
 https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/lastCompletedBuild/testReport/


 On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:

 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:

 Why too much rush ?

 I just find it more convenient to have everything in Git. Makes the 
 testing cycle more pleasant and the git svn workflow isn't something I 
 personally enjoy. I'm working on the core and it's nothing more than a 
 preference.

 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)

 I'll answer these in another post. With the documentation, that will be 
 easier.


 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!


 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)

 Something else when building core with ant bootstrap (sure not really
 important :-)):

 process-classes:
[echo] Using plexus version 1.5.5
[java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
[java] SLF4J: Defaulting to no-operation (NOP) logger implementation
[java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.


 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)

 Sorry I didn't investigate more on the reason.

 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).

 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.

 Kristian

 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

 /Anders

 On Thu, Oct 11, 2012 at 6:18 AM, Kristian Rosenvold
 kristian.rosenv...@zenior.no wrote:
 So you're going to be working on the core without touching the it's?

 Seriously, this discussion is going nowhere. We move both and someone
 speeds 45 minutes fixing the it's.

 Kristian

 Den 11. okt. 2012 kl. 00:54 skrev Jason van Zyl ja...@tesla.io:

 I think we can flip the core, we can still release the core without 
 flipping the integration tests.

 It might actually be

Re: Flipping Maven Core to Git

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 ja...@tesla.io 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 
 kristian.rosenv...@gmail.com 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 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

Re: Flipping Maven Core to Git


On Oct 11, 2012, at 8:42 AM, Olivier Lamy ol...@apache.org wrote:

 2012/10/11 Jason van Zyl ja...@tesla.io:
 Yup, the ITs don't seem to run when changes are made. Are they manually 
 triggered? I waited last night for a while but nothing was happening.
 there are triggered by changes in
 http://svn.apache.org/repos/asf/maven/maven-3/trunk or in core its
 source tree.
 If I correctly read here
 https://builds.apache.org/view/M-R/view/Maven/ they runed around 13H
 ago (depending on nodes some are not used a lot by other asf projects)
 13H ago is very similar to your last commit time
 

I waited a while, and if both systems are on UTC the difference between the 
checkin and the build is an hour.

Checkin:
Wed Oct 10 22:48:14 2012 UTC (14 hours, 8 minutes ago)
http://svn.apache.org/viewvc?view=revisionrevision=1396843

Build:
#203 (Oct 10, 2012 11:07:47 PM) (13 hours ago)

Is it tied to LDAP as I tried to login to trigger the build manually but I 
couldn't log in.

 
 On Oct 11, 2012, at 8:30 AM, Olivier Lamy ol...@apache.org wrote:
 
 2012/10/11 Jason van Zyl ja...@tesla.io:
 I can look at both of those, maybe we can figure something out in the 
 simple implementation to make it look better. Ant thing looks easy enough 
 to fix.
 nice.
 BTW some its are failing too:
 https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/lastCompletedBuild/testReport/
 
 
 On Oct 11, 2012, at 5:31 AM, Olivier Lamy ol...@apache.org wrote:
 
 2012/10/11 Jason van Zyl ja...@tesla.io:
 
 On Oct 11, 2012, at 4:19 AM, Olivier Lamy ol...@apache.org wrote:
 
 Why too much rush ?
 
 I just find it more convenient to have everything in Git. Makes the 
 testing cycle more pleasant and the git svn workflow isn't something I 
 personally enjoy. I'm working on the core and it's nothing more than a 
 preference.
 
 Perso, I will be happy to see similar rush on writing test/doc the
 stuff committed 1,5 month ago !.(despite a number of ping)
 AFAIK (maybe I miss something) using @Inject is not so trivial because
 we need to generate the sisu index.
 Which is very similar to what we do currently with plexus plugins
 which generate metadata.
 So what is the added value for users or plugin developers (except
 using the last à la mode @Inject).
 I will be happy to hear the added values (performance ? etc .. ?)
 
 I'll answer these in another post. With the documentation, that will be 
 easier.
 
 
 regarding last commit regarding logs in trunk, I tested that and the
 artifact transfer progress(download/upload) is now (IMHO) very crappy
 !!
 
 
 I'm not sure technically what very crappy means. You mean the way it 
 visually looks?
 Yup visible changes for users will be a tons of lines in the console.
 Maybe it's just matter of log layout to configure (As I didn't have a
 look I don't know)
 
 Something else when building core with ant bootstrap (sure not really
 important :-)):
 
 process-classes:
   [echo] Using plexus version 1.5.5
   [java] SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
   [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
   [java] SLF4J: See
 http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 
 
 [INFO] Building SCM Publish Maven Plugin 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 [INFO] 4/16 KB
 [INFO] 8/16 KB
 [INFO] 12/16 KB
 [INFO] 16/16 KB
 [INFO] 16/16 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 (16 KB at 9.2 KB/sec)
 [INFO] Downloading:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 [INFO] 4/47 KB
 [INFO] 8/47 KB
 [INFO] 12/47 KB
 [INFO] 16/47 KB
 [INFO] 20/47 KB
 [INFO] 24/47 KB
 [INFO] 28/47 KB
 [INFO] 31/47 KB
 [INFO] 35/47 KB
 [INFO] 38/47 KB
 [INFO] 42/47 KB
 [INFO] 46/47 KB
 [INFO] 47/47 KB
 [INFO]
 [INFO] Downloaded:
 https://archiva-repository.apache.org/archiva/repository/public/org/apache/maven/plugins/maven-plugin-plugin/3.1/maven-plugin-plugin-3.1.jar
 (47 KB at 45.8 KB/sec)
 
 Sorry I didn't investigate more on the reason.
 
 2012/10/11 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Jason ran the tests based off the git repo and they were fine. There
 is no problem (I've had my fair share of troubles with the core it's
 so it's probably been a problem between chair and keyboard).
 
 Unless someone objects I'll file a INFRA jira to port m3-core + IT's
 sometime later today.
 
 Kristian
 
 2012/10/11 Anders Hammar and...@hammar.net:
 So, what is the solution to fixing the ITs that depend on an empty
 folder? Put some dummy file there? But then the folder will not be
 empty...

Re: Flipping Maven Core to Git

To that end we should probably also try to collect any specific ITs for plugins 
that are currently in the IT suite and put them with their respective plugins. 
I think the idea of knowing what you're forking is wise. It would be really 
hard for someone to know we have tests for specific plugins in the ITs and that 
they should be run to validate a particular plugin.

On Oct 11, 2012, at 5:40 AM, Kristian Rosenvold kristian.rosenv...@gmail.com 
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 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

Re: Flipping Maven Core to Git

2012/10/11 Arnaud Héritier aherit...@gmail.com

 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 ?


If you make any kind of change on a branch (bugfix/feature/whatever) I
would
expect to have test updates being done on that branch too, so the branch
represents a complete diff of the change; both feature and tests.

When the fix/feature is merged back into master the tests come along, if
the feature is
never merged to master, the tests stay in their branch - just like they
should.

This is a healthy mode of operation; if you look at the branches in my
surefire github repo
(https://github.com/krosenvold/maven-surefire) I have like 15 different
branches.
Some of them are specific JIRAs and may contain testcases and partial
fixes. Now I will
start pushing these to the ASF git repo instead, since they represent work
on an issue
that is not fully fixed; maybe just a testcase or a test project.

 I think it's important we acknowledge the existence/intention of such
branches on
the corresponding JIRA when we make such feature branches in the official
repo.
If I just push it to my personal github repo it can be as messy as I
prefer, but when
I push it to ASF I'd prefer it to have reasonably well-defined
responsibility (like test-case,
suggested fix or similar) and some value to others. If it's just my
personal doodles I'll
keep them in my personal github.

As for branches that never get merged back; well that's life and usually
there's a story
 behind that and we tell it in jira.

Kristian

Re: Flipping Maven Core to Git

Say I have the following scenario:

I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x and 
create some ITs. What's the plan with making sure that we have one cohesive set 
of ITs that we can use across all versions? Just merge additions back into 
every branch? Because we would need to checkout two copies in order to be at 
one branch for the version of Maven you're working on and the branch where the 
ITs are. I understand wanting a rationalized fork and with unit tests I 
understand, but did you forks of large OSS projects include ITs like this?

If that workflow is sorted out it seems fine. I just don't want it to be 
onerous to achieve the discipline of having on coherent set of tests that work 
across all versions of Maven. It's pretty easy to make that consistent right 
now. There's not a huge number of branches so merging additions back to each 
branch is pretty easy. Is that what you had in mind?


On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 2012/10/11 Arnaud Héritier aherit...@gmail.com
 
 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 ?
 
 
 If you make any kind of change on a branch (bugfix/feature/whatever) I
 would
 expect to have test updates being done on that branch too, so the branch
 represents a complete diff of the change; both feature and tests.
 
 When the fix/feature is merged back into master the tests come along, if
 the feature is
 never merged to master, the tests stay in their branch - just like they
 should.
 
 This is a healthy mode of operation; if you look at the branches in my
 surefire github repo
 (https://github.com/krosenvold/maven-surefire) I have like 15 different
 branches.
 Some of them are specific JIRAs and may contain testcases and partial
 fixes. Now I will
 start pushing these to the ASF git repo instead, since they represent work
 on an issue
 that is not fully fixed; maybe just a testcase or a test project.
 
 I think it's important we acknowledge the existence/intention of such
 branches on
 the corresponding JIRA when we make such feature branches in the official
 repo.
 If I just push it to my personal github repo it can be as messy as I
 prefer, but when
 I push it to ASF I'd prefer it to have reasonably well-defined
 responsibility (like test-case,
 suggested fix or similar) and some value to others. If it's just my
 personal doodles I'll
 keep them in my personal github.
 
 As for branches that never get merged back; well that's life and usually
 there's a story
 behind that and we tell it in jira.
 
 Kristian

Thanks,

Jason

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

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: Flipping Maven Core to Git

NIce use case, this is where things get interesting ;) Initially I'll just
add that this is one of those workflows that might be easier with a
separate IT repo. This is how the flow would be in a merged single repo:

This workflow has two distinct modes of operation:

1. You always check out the oldest appropriate branch to make the IT. So if
the IT should apply to 2.2.1 you should check that out. (If we need to make
IT's that go even further back I think it might be easiest to just keep the
IT's in a separate repo since it gets really hard to actually *make* that
repo.)

2 A) You are working in a properly branched structure that is mergeable ;
i.e. what we might do between 3.0.X and 3.1 or maybe more appropriately
between 3.X and 4.X.

Make all the changes your heart desires, in any kind of commit sequence you
prefer. The downstream merge to the subsequent version will fix it all.

2 B) You are working i an unmergable branch structure (2.2.1-3.0)

Add the IT as a distinct commit on the 2.2.1 branch, make sure any bug-fix
you do is done as a separate commit from the IT. When done, you will need
to check out the 3.0.X branch and cherry pick the commit with the  IT. From
3.0.X on it will merge properly. cherry-picking is a manual operation and
if you forget it, the IT will be lost on 2.2.1

While this all may seem a bit complex, it's basically the nuts  bolts of
how day-to-day life of a branched workflow functions. When working in older
history, it's usually wise to partition work into well-defined commits,
because sometimes you might end up cherry-picking only parts of the work
forward. When you're on trunk you usually don't need to worry about this
stuff.

{begin Theoretical Technical digression for the git-savy}
Theoretically we should be able to make a single phoney merge commit that
re-establishes the mergeability between the 2.2.1 and 3.0.X branch so that
any subsequent changes we make to 2.2.1 can merge directly downstream. I
have not done this in practice but I'm sure some others here have. I'm
thinking something like this:
git checkout maven3.0.X
git merge -s ours origin/maven-2.2.1

Now of course I want to test this out before we proceed
{end Theoretical Technical digression for the git-savy}


Kristian


2012/10/11 Jason van Zyl ja...@tesla.io

 Say I have the following scenario:

 I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x and
 create some ITs. What's the plan with making sure that we have one cohesive
 set of ITs that we can use across all versions? Just merge additions back
 into every branch? Because we would need to checkout two copies in order to
 be at one branch for the version of Maven you're working on and the branch
 where the ITs are. I understand wanting a rationalized fork and with unit
 tests I understand, but did you forks of large OSS projects include ITs
 like this?

 If that workflow is sorted out it seems fine. I just don't want it to be
 onerous to achieve the discipline of having on coherent set of tests that
 work across all versions of Maven. It's pretty easy to make that consistent
 right now. There's not a huge number of branches so merging additions back
 to each branch is pretty easy. Is that what you had in mind?


 On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:

  2012/10/11 Arnaud Héritier aherit...@gmail.com
 
  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 ?
 
 
  If you make any kind of change on a branch (bugfix/feature/whatever) I
  would
  expect to have test updates being done on that branch too, so the branch
  represents a complete diff of the change; both feature and tests.
 
  When the fix/feature is merged back into master the tests come along, if
  the feature is
  never merged to master, the tests stay in their branch - just like they
  should.
 
  This is a healthy mode of operation; if you look at the branches in my
  surefire github repo
  (https://github.com/krosenvold/maven-surefire) I have like 15 different
  branches.
  Some of them are specific JIRAs and may contain testcases and partial
  fixes. Now I will
  start pushing these to the ASF git repo instead, since they represent
 work
  on an issue
  that is not fully fixed; maybe just a testcase or a test project.
 
  I think it's important we acknowledge the existence/intention of such
  branches on
  the corresponding JIRA when we make such feature branches in the official
  repo.
  If I just push it to my personal github repo it can be as messy as I
  prefer, but when
  I push it to ASF I'd prefer it to have reasonably well-defined
  responsibility (like test-case,
  suggested fix or similar) and some value to

Converting Maven Core to Git

Hi,

Where are the scripts that were used to convert the other repos to Git? I'm 
going to spend tomorrow trying to convert Maven core over to Git as trying to 
finish the other work I'm trying to do and using Subversion is getting in my 
way so I'd just like to be done with moving the core over to Git. Pure selfish 
motivation.

Thanks,

Jason

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

What matters is not ideas, but the people who have them. Good people can fix 
bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: Converting Maven Core to Git

2012-10-10 Thread Kristian Rosenvold

The repo is already ported, it's just a matter having infra flip some
switches. ISTR there are some issues that need to be fixed in the core
it's when running from a git repo

Those issues can be fixed now ;)

Kristian

Den 10. okt. 2012 kl. 18:28 skrev Jason van Zyl ja...@tesla.io:

 Hi,

 Where are the scripts that were used to convert the other repos to Git? I'm 
 going to spend tomorrow trying to convert Maven core over to Git as trying to 
 finish the other work I'm trying to do and using Subversion is getting in my 
 way so I'd just like to be done with moving the core over to Git. Pure 
 selfish motivation.

 Thanks,

 Jason

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

 What matters is not ideas, but the people who have them. Good people can fix 
 bad ideas, but good ideas can't save bad people.

 -- Paul Graham






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Converting Maven Core to Git

So what exactly is left to be done and can they be done now. I'm trying to 
finish my work and I would just not do this with subversion at all.

On Oct 10, 2012, at 12:43 PM, Kristian Rosenvold kristian.rosenv...@zenior.no 
wrote:

 The repo is already ported, it's just a matter having infra flip some
 switches. ISTR there are some issues that need to be fixed in the core
 it's when running from a git repo
 
 Those issues can be fixed now ;)
 
 Kristian
 
 Den 10. okt. 2012 kl. 18:28 skrev Jason van Zyl ja...@tesla.io:
 
 Hi,
 
 Where are the scripts that were used to convert the other repos to Git? I'm 
 going to spend tomorrow trying to convert Maven core over to Git as trying 
 to finish the other work I'm trying to do and using Subversion is getting in 
 my way so I'd just like to be done with moving the core over to Git. Pure 
 selfish motivation.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 What matters is not ideas, but the people who have them. Good people can fix 
 bad ideas, but good ideas can't save bad people.
 
 -- Paul Graham
 
 
 
 
 
 
 -
 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
-

We know what we are, but know not what we may be.

  -- Shakespeare

Flipping Maven Core to Git

So in chatting with Kristian it appears the the core is ready to flip, while 
the integration tests need some work. Can we flip the core and work on the core 
integrations test afterward?

Thanks,

Jason

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

A language that doesn’t affect the way you think about programming is not worth 
knowing. 
 
 -- Alan Perlis

Re: Flipping Maven Core to Git

2012-10-10 Thread Anders Hammar

I see no reason they need to be migrate at the same time.

/Anders

On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, while 
 the integration tests need some work. Can we flip the core and work on the 
 core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is not 
 worth knowing.

  -- Alan Perlis






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Flipping Maven Core to Git

2012-10-10 Thread Kristian Rosenvold

It's just two simple projects that have some very simple fixes that
need to be done (git does not preserve empty directories and I seem to
recall that a couple of it's failed due to this).

I say we do the 3.1 release off git ;) Move both.

Kristian


2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, while 
 the integration tests need some work. Can we flip the core and work on the 
 core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is not 
 worth knowing.

  -- Alan Perlis






 -
 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

Re: Flipping Maven Core to Git

2012-10-10 Thread Anders Hammar

I like the sound of 3.1:-)

/Anders

On Wed, Oct 10, 2012 at 8:36 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 It's just two simple projects that have some very simple fixes that
 need to be done (git does not preserve empty directories and I seem to
 recall that a couple of it's failed due to this).

 I say we do the 3.1 release off git ;) Move both.

 Kristian


 2012/10/10 Anders Hammar and...@hammar.net:
 I see no reason they need to be migrate at the same time.

 /Anders

 On Wed, Oct 10, 2012 at 7:53 PM, Jason van Zyl ja...@tesla.io wrote:
 So in chatting with Kristian it appears the the core is ready to flip, 
 while the integration tests need some work. Can we flip the core and work 
 on the core integrations test afterward?

 Thanks,

 Jason

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

 A language that doesn’t affect the way you think about programming is not 
 worth knowing.

  -- Alan Perlis






 -
 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

Re: Flipping Maven Core to Git