We try to move the code forwards, but old code bases are "interesting"; you have to make sure you keep track of your goals.
What I am trying to say is that when I think of rouge threads writing in unsynchronized data; I immediately get flashbacks of the gunman in pulp fiction (Samuel L Jackson I believe) who appropriately misquotes bible statements before killing people. This is the guy you're bringing into your build. I just tried to be entirely clear about the threading model that is actually in effect in maven core, which actually works. If your mojo starts writing to shared state from a different thread all hell will be loose. If you do it from the correct thread, things should work. If the problem is present when the mojo threads correctly, I'm all in favour of fixing the problem. If the problem occurs because the mojo violates the threading contract, I'm kind of luke-warm about fixing the issue, since you will open the floodgates of mordor and all the evilness of the old world will come seeping through the cracks. But a fully concurrent maven core that does away with the one mojo one thread model is a huge undertaking, and probably not worth the effort. We had quite a few interesting discussions on optimizing performance. Right now I am working on fully concurrent zip creation in commons-compress, this should come for "free" to all of maven in next plexus-archiver release. There is also stuff like the excellent discussions I've been having with Vladimir Sitnikov in http://jira.codehaus.org/browse/MSHARED-394. Fixing that should have a huge pontential upside. Other than that; build performance is mostly about compiler-plugin and tests. Kristian 2014-12-31 12:42 GMT+01:00 Tibor Digana <tibordig...@apache.org>: > Don't worry Kristian, you did great job in parallel Maven exec, honestly I > don't say opposite! > As the CPUs speed up and disks as well, we really need parallal executions > in Maven core. > The thing how the discussion started in emails is that i wrote some local > changes and opened PR > https://github.com/apache/maven/pull/34 > > IMHO the Maven is getting older and compettitors like Graddle will have > chance to get more users than Maven. > The thing is to keep current Maven users and plugin vendors and make > "stable" Maven. > Also we should introduce what people like, means sciptable languages in POM > like BashShell, Groovy. > > I guess compiling Maven in Java8 no user has benefit of unless using > Java-like language in POM. > Some plugins attempt to do so already. > I am aware of the strong argument of not-cracking POM structures with code > and the idea of configuring projects on regular basis, but there should some > ballance between. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-Commit-3b671d07340b002e13775883d09e7f7e0d9a3c49-tp5821660p5821839.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
