The problem is, this was a regression issue, based on real improvements
we made to the interpolation code in 2.0.9.
To boot these issues to 2.1, we'd need to find a way to reintroduce
buggy handling of build paths into the interpolator.
Brian E. Fox wrote:
I agree it should be right, but a 3x hit in build times isn't acceptable. Given
the alternative, I would probably boot those issues to 2.1 where they can be
handled correctly. The majority of users probably aren't getting hit by these
bugs, so forcing the performance hit on them will appear as a regression, not
an improvement.
-----Original Message-----
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 10:18 AM
To: Maven Developers List
Subject: Re: Maven 2.0.10-RC5
Brett,
This change was in place long before the javadoc plugin problem of the
last RC. The problem happens when forking at times, too, since those
forked lifecycles sometimes require alternative target directory, etc.
If that information has already been interpolated, changeing target
directory and associated paths gets problematic quickly.
The fact that any plugin can change project state at will means that we
have to be able to propagate these changes to the next plugin. Dirty
flags aren't enough here, since it could be literally anywhere in the
Model object hierarchy, in the various collections housed in the project
instance, etc.
I'm happy to take a less invasive approach here, *if* we can find a way
to make behavior consistent. IMO consistency is much more important than
speed. In a perfect world, we'd control the mutability of project and
build state more carefully, or even retain a more efficient data tree
that we could use to incorporate changes and update build paths, plugin
configs, etc. more quickly. The approach I added was geared to fit
within the constraints of the current data model.
-john
Brett Porter wrote:
Hey John,
Is it necessary for the project on every execution? I thought this was
just for ${reactorProjects} - which could be handled on demand in the PPEE?
It might be worth running the profiler over it too to see if there are
any particular hotspots that could improved regardless.
- Brett
On 04/08/2008, at 10:55 PM, John Casey wrote:
This may have to do with some very inefficient code I had to put in to
solve MNG-3530. It's doing interpolation of the build section of the
POM per-plugin now, and restoring it to the dynamic state just after
each plugin executes. This was necessary to allow modifications to the
project instance happening during a plugin's execution to be seen in
successive plugins.
The execution should be correct now, but unfortunately the design of
the system prevented an efficient solution. If you would like to look
over the code, it's in the MavenProject.calculateConcreteState(..),
MavenProject.restoreDyanmicState(..), PluginManager.executeMojo(..),
PluginParameterExpressionEvaluator.evaluate(..), and
PluginManager.getReport(..) methods.
I'd love suggestions.
-john
Jörg Schaible wrote:
Hi,
John Casey wrote:
Hi,
Here's your daily dose of Maven 2.0.10! I've fixed the regressions
pointed out in RC4, and added integration tests to guard
against their
reintroduction. The new release candidate can be found here:
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC
5/org/apache/maven/apache-maven/2.0.10-RC5
The release notes (again):
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=105
00&styleName=Html&version=14112
Please try it out and let me know if things go wrong.
Does someone else than me also notice a major performance decrease?
If I perform a build for our ~150 artifacts it takes with M2010RC5
~3h while the same task consumes about 40min with M209. Similar
results when generating the Eclipse projects.
- Jörg
---------------------------------------------------------------------
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]
--
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]
