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
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 personall
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 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
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
> I could not resist, I made this r
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.
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 ol
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
2012/10/11 Arnaud Héritier
> 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
ents 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 eithe
On Oct 11, 2012, at 8:42 AM, Olivier Lamy wrote:
> 2012/10/11 Jason van Zyl :
>> 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
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
2012/10/11 Jason van Zyl :
> 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 correc
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 wrote:
> 2012/10/11 Jason van Zyl :
>> I can look at both of those, maybe we can figure something out in the simple
>> implementatio
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 wrote:
> 2012/10/11 Jason van Zyl :
>> I can look at both of those, maybe we can figure something out in the si
2012/10/11 Jason van Zyl :
> 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-mave
.@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 :
>> >
>> > On Oct 11, 2012, at 4:19 AM, Olivier Lamy wrote:
>> >
>> >> Why
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/1
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 simultane
e 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 h
le
> - 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.
>>
>
>
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 wrote:
> 2012/10/11 Jason van Zyl :
>>
>> On Oct 11, 2012, at 4:19 AM, Olivier Lamy wrote:
>>
>>>
2012/10/11 Jason van Zyl :
>
> On Oct 11, 2012, at 4:19 AM, Olivier Lamy 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 an
On Oct 11, 2012, at 4:19 AM, Olivier Lamy 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.
+1
On Oct 11, 2012, at 5:09 AM, Arnaud Héritier wrote:
> 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 <
> kri
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
sage -
>> From: Arnaud Héritier
>> To: Maven Developers List
>> Cc: Mark Struberg
>> 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
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
t tagged. I
> actually would even really appreciate that fact!
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>> From: Kristian Rosenvold
>> To: Maven Developers List
>> Cc:
>> Sent: Thursday, October 11, 2012 8:35 AM
>>
On Oct 11, 2012, at 12:18 AM, Kristian Rosenvold
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 a
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
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 10:19 AM
> Subject: Re: Flippi
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
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 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)
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 agai
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 possib
aud Héritier
> To: Maven Developers List
> Cc: Mark Struberg
> 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
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 repo
$ 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-set
ber 11, 2012 9:02 AM
> Subject: Re: Flipping Maven Core to Git
>
> 2012/10/11 Mark Struberg :
>> 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
On Thursday, 11 October 2012, Kristian Rosenvold wrote:
> 2012/10/11 Mark Struberg >:
> > 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 c
2012/10/11 Mark Struberg :
> 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
eally appreciate that fact!
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List
> 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 the
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.
Kristia
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
wrote:
> So you're going to be working on the core without touching the it's?
>
> Seriously,
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 :
> I think we can flip the core, we can still release the core
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
wrote:
> It's just two simple projects that have some very simple fixes
I like the sound of 3.1:-)
/Anders
On Wed, Oct 10, 2012 at 8:36 PM, Kristian Rosenvold
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).
>
>
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 :
> I see no reason th
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 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 integration
49 matches
Mail list logo
