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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
