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 line thing is one option. The other thing I thought about is to somehow burn in the few plugins that this affects (clover, cobertura, maybe others) that we know about. We possibly could add something into the <configuration> things to signal it or a <special.plugins>clover,cobertura</..> property that we look for or similar, but that still would require modifying the poms which kind of violates your "just run mvn install" thing. Maybe burn in the ones we know and allow the pom mod for those we don't know. Honestly, if it was completely my call, I would say pursue option #2 and release it as 2.1, not 2.0.10. Dan On Wednesday 20 August 2008 9:37:04 pm Brian E. Fox wrote: > 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 know better. This > is against the "I can just run mvn install on any maven project and it > works" philosophy. > > John, in absence of an annotation, is there any way to signal from the > pom that this is needed (ideally per plugin execution even) > > > > -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2008 9:07 PM > To: Maven Developers List > Subject: 2.0.10 performance..... > > > 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? -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
