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, so to me it makes more sense to sync 2.1.x up with
the RC branch (the 2.1.x branch should accept all of the RC branch
changes, and incorporate the new code such as Dan's and Ralph's work). I
guess I'm not sure how to interpret the 'selective' part of option 1.
Then, we can roll back the 2.0.x branch and decide how to move forward
there to fix the worst problems with 2.0.9. The extent of changes in the
RC branch make it a little risky to say the least for a 2.0.10 release.
It's not that it's functionally that different from the other 2.0.x
releases, but the implementations have changed significantly.
At any rate, we've put in an awful lot of work on this RC branch to
simply discard the stability we've achieved and resume work toward some
as-yet-undetermined release date.
I have a strong preference to get the code in the RC branch released
under *some* version very soon now, then regroup to incorporate any
changes from Dan or Ralph that might destabilize things again. There are
important fixes in this code, and one of the big advantages of pushing
trunk to 3.0.x was to allow a release of intermediate code in the near
future...let's not throw that away.
Ralph Goers wrote:
My non-binding preference is for option 1. I'm not crazy about renaming
2.0.10-RC. I'd really be surprised if merging that to 2.1.x would be
all that hard.
Brett Porter wrote:
This doesn't particularly appeal to me. maven-2.0.x is stranded in a
half merged state.
The current 2.1.x was cut from 2.0.x and I figured we'd just merge
everything that hit maven-2.0.x.
I'd prefer one of
1) merge all your stuff selectively to 2.1.x (along with Dan's
changes), and roll 2.0.x back (but keep other bug fixes we can release
as 2.0.10)
2) carry on the 2.0.10 approach
It seems like 2 is becoming less feasible though due to the extent of
changes it has needed for an RC branch?
Maybe not completely thought through - I'm rushing out the door for a
long weekend :) Will respond to your other mails Monday.
Cheers,
Brett
On 22/08/2008, at 7:59 AM, John Casey wrote:
I would say that we should simply rename the 2.0.10-RC branch as
2.1.0-RC, and call that the branch used for releasing 2.1.0, with the
current 2.1.x branch being used for 2.1.1 as its first release. I'd
always intended to keep the changes I've made in the RC branch merged
with what was then 2.0.x, and though I've fallen a bit behind, I
still think that's necessary. So, Dan's reactor changes would simply
be a new feature in 2.1.1, building on 2.1.0, which would be the
release coming out of the current RC work.
Thoughts?
-john
Brian E. Fox wrote:
I agree. We'd have to figure out how to merge Dan's reactor changes in
as I'm not sure where the 2.1 branch came from that he used. I would
probably rename the 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,
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 implementation is certainly different
enough to warrant it.
Ralph Goers wrote:
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
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 think the sheer number of transitions between
concrete and dynamic state are just crushing the life out of this.
I talked briefly with you, Dan, yesterday about detecting whether
some
key parts of the project/model graph had changed, and using those
to trigger a concrete -> dynamic transition...otherwise, leaving
the project in concrete mode until such a trigger trips. Thinking
about this more, I think we could easily cover 90% of use cases
with this approach, right off the bat. From that point, we could
probably hone the detection system over time to pick up on
anything we missed. I think this has a lot of potential to improve
the performance numbers,
and it's something I've just started to pursue here.
I'm not wild about adding the new annotation for now, simply
because of the time and pain involved in bringing all of the
affected plugins
up to snuff (they'd have to have new releases as well). 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 waaaay too heavy to do at
runtime.
Additionally, as for adding a command-line option: this would
definitely work, but it would be putting the onus on the user to
adapt
to our deficient design. It would inevitably increase the
confusion around the use of Maven ("When do I use the dynamic
flag, when can I skip it...why should I care?") and in any case
I'm concerned about building up more legacy to support in things
like that, once we find
a
real solution to the problem.
For now, I'm going to look more closely into these trigger values.
Please let me know if you have any ideas...
Thanks,
-john
Daniel Kulp wrote:
The latest stuff on John's branch is "better", but it's still
about 4x - 5x slower for some of the actions I do several times a
day. I'd estimate that I'd end up wasting 20-30 minutes a day
waiting for
it compared to 2.0.9. I find that unacceptable and wouldn't be able
to recommend it get rolled out to other developers. I couldn't
"cost justify" reducing the productivity of everyone.
However, the dynamic re-interpretation stuff is needed due to a
few plugins doing some strange things. (clover, cobertura, etc...)
The
problem is that it causes a major slowdown for ALL plugins, even the
"well behaved" plugins.
My suggestion would be:
1) Leave the reinterpret code in, but turn it off by default. Add
a
command line flag or system property to turn it on in the cases that
it's needed. The default behavior would be no worse than 2.0.9.
2) Extend the plugin model to add a "@modifiesBuildEnvironment"
or something similar so a plugin can let the execution
environment know
that special care will need to be taken after this plugin runs.
Once that is in place, future versions of the affected plugins could
set that to make sure things work correctly.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
