Philippe>The decision for no maven in project was due to the fact that nobody had time to work on it and as project has a lot of other work needed, we wanted to put efforts in other fields.
Oh, really? What about moving files around in order to better follow "default maven convention"? Philippe>also project may be hard to mavenize knowing all the customization needed. I do get that, and I am fine with the challenge provided one day that would become the master build script for the project. I thought sebb was against Maven as: 1) it is slower to build. That is true, Maven has non-zero per-module overhead. 2) "it adds no value". Well, I would argue that having Maven-first makes JMeter presence in Maven Central much more solid, and it greatly simplifies use of JMeter as a dependency. 3) "it makes builds more complicated" I know file rearrangements will hurt "svn blame" kind of scenarios a bit, however default layout conventions do help IDEs to work with the project. PS. Currently Gradle is the thing, and it is more flexible when it comes to multi-module configurations. It is has faster build times (it might be even faster than current Ant builds), so I guess we might want to try Gradle if the build speed is an issue. PPS. I've did mavenization / code relayout for pgjdbc, and I do release pgjdbc, so it (me speaking of mavenization) is not something theoretical. PPPS. I've not used Gradle extensively. So, even if I would try adding Gradle build scripts, I would like someone to check those for the sanity. Vladimir
