Hi John,
On 22/08/2008, at 10:35 AM, John Casey wrote:
As far as selective merging to 2.1.x, of course we'll keep things
like Dan's change, but where does that leave all of the stabilizing
work on the RC branch? Most of the substantive changes in the RC
branch is also in the 2.1.x branch,
ok, I found the right one. We've put people into maven-developers in
the past for this type of thing even when they weren't committers, but
instead I've created a maven-contributors group we can use (that only
has edit and assign permissions) for anyone that shows genuine
interest in contri
Thanks.
You have 3 JIRA accounts, which is the one you use?
- Brett
On 23/08/2008, at 3:32 PM, Paul Benedict wrote:
Brett,
If someone would agree to kindly grant me karma to update issue
titles, I'll change them for you.
Paul
On Thu, Aug 21, 2008 at 6:07 PM, Brett Porter <[EMAIL PROTECTED]
Brett,
If someone would agree to kindly grant me karma to update issue
titles, I'll change them for you.
Paul
On Thu, Aug 21, 2008 at 6:07 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> On 22/08/2008, at 8:20 AM, Paul Benedict wrote:
>
>> Well, before anyone begins doing 2.1 work, take the 3.0.
That has to be randomness in your test timings, assuming you didn't use
the new command line arguments. At best my changes should have no
positive effect on performance. :-)
-Dan
Ralph Goers wrote:
Well, I didn't really look at what you did, but I noticed that it did improve
my test times a
Well, I didn't really look at what you did, but I noticed that it did
improve my test times a little.
Dan Fabulich wrote:
A lot of good discussion here. Just as a reminder, my changes are one
very small check-in, in code that shouldn't have changed since August
12. It should be easy to merg
A lot of good discussion here. Just as a reminder, my changes are one
very small check-in, in code that shouldn't have changed since August 12.
It should be easy to merge, or even to back out and reapply if for some
reason that were necessary.
http://svn.apache.org/viewvc?view=rev&revision=
Sure. Just so you know I am running this on Ubuntu running in a VM
under Windows on a Thinkpad T60. It has 3GB of memory of which I've
given 1.5GB to Linux. I do have a faster machine but I've been working
on my stuff on the laptop.
I ran the builds all over again and got slightly different
Would you mind running with the latest code on the RC branch? I ran it,
but I'm not sure I have the environment setup the way people would
expect. The SVN for that branch is:
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.10-RC
Ralph Goers wrote:
Yeah, I don't think you
John,
Just a quick note before I head off to bed
With the latest code on the 2.0.10-RC branch, my CXF test is now down to 44
seconds. (2.0.9 is about 33 secs) Memory usage is about the same:
2.0.9: 53M/94M
2.0.10-RC: 55M/100M
This is "mvn -Pfastinstall" from a non-clean build. Ba
Yeah, I don't think you need to be all that selective. I agree that
2.1.0 needs all the work you've been doing. I just ran the cxf build on
the 2.1.x branch. Here are the results I get when running mvn
-Pfastinstall install:
4:49 for 2.0.9,
8:51 on 2.1.x
8:41 on 2.1.x with my changes.
Memory
from the
current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-----
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday,
August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought
k the 2.0.x branch to 2.0.9 and start cherry picking
pieces to merge in and make 2.0.10.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 6:04 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
Brett created the 2.1.x branch on A
ieces to merge in and make 2.0.10.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 6:04 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
Brett created the 2.1.x branch on Aug 12. I believe it was from whatever
was currently i
e
current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday,
August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought to becom
he current 2.0.10 branch to 2.1.x, then merge the
branch dan used into it. We could then port the real bug fixes from
the
current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday,
Augus
On 22/08/2008, at 8:20 AM, Paul Benedict wrote:
Well, before anyone begins doing 2.1 work, take the 3.0.x tickets and
update the descriptions of them. Many 3.0 tickets still descibe "2.1"
in their title.
The versions are right... changing descriptions is probably more
hassle than it is wort
urrent 2.0.10 branch to 2.1.x, then merge the
>>>> branch dan used into it. We could then port the real bug fixes from the
>>>> current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
>>>> yet?
>>>>
>>>> -Original Message-
Sent: Thursday,
August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought to become 2.1.0. I think most of us
are
thinking similar things at this point (based on conversations I've
seen here and on IRC), and its implement
sed into it. We could then port the real bug fixes from the
current 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday,
August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performan
I've got a setup running now that checks for changes in build paths and
properties after a mojo runs, and transitions back to dynamic mode iff
there are changes...otherwise, it leaves it in concrete mode for the
next mojo execution. This works fairly well: Running the following command:
mvn -P
10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought to become 2.1.0. I thi
fused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought to become 2.1.0. I think most of us are
thinking similar things at this
ent 2.0.10 back to the 2.0.x branch and do a new 2.0.10. Confused
yet?
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 1:32 PM
To: Maven Developers List
Subject: Re: 2.0.10 performance.
I'd say the 2.0.10 release ought to become 2.1.0
>As for detecting
>project-state changes in the plugin itself (or the POM, as Brian asked
>about) we'd have to scan the entire logic of the mojo (and classes it
>used) to see whether any of it modified the project/model graph...which
>is obviously wy too heavy to do at runtime.
Actually wh
I'd say the 2.0.10 release ought to become 2.1.0. I think most of us are
thinking similar things at this point (based on conversations I've seen
here and on IRC), and its implementation is certainly different enough
to warrant it.
Ralph Goers wrote:
I'm still wondering if given the impact this
I'm still wondering if given the impact this has shouldn't it be pulled
from 2.0.x and moved into 2.1? In my view the purpose of 2.1.x is it
lock down 2.0.x to bug fixes that don't introduce new behaviors.
John Casey wrote:
So, I've been working on the hotspots (late last night and again this
So, I've been working on the hotspots (late last night and again this
morning) trying to see what improvements I could make. In the end, I was
able to improve things a bit in terms of interpolation efficiency and
model cloning (turned out that was a big time sink too). However, in the
end I thi
PROTECTED]
> Sent: Wednesday, August 20, 2008 10:06 PM
> To: dev@maven.apache.org
> Subject: Re: 2.0.10 performance.
>
>
> Well, ideally to me, we'd just pursue option #2 and push that through.
> The
> problem is that doing so would delay 2.0.10 even further as
Honestly I half feel like flushing the fixes for all of this to 2.1 and
leaving it as is in 2.0.x.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 10:06 PM
To: dev@maven.apache.org
Subject: Re: 2.0.10 performance.
Well, ideally to me
Well, ideally to me, we'd just pursue option #2 and push that through. The
problem is that doing so would delay 2.0.10 even further as that would
require another plugin-tools release (which was just released today), etc
Thus, the question is, what to do to get 2.0.10 out? The command l
I like both of those ideas.
My concern since we saw the performance issues was that it was affecting
everyone to fix just a few cases. If it could be off by default it would
be better, but setting a cli flag for this isn't a great use case...then
there's no way to specify it for people who wouldn't
32 matches
Mail list logo
