I notice that JMeter does not use Maven to build. It also does not publish artifacts to Maven central either ( see 49753 ). I am opening this issue more or less to query folks to see if converting the JMeter build process to a Maven project structure and build is something that would be acceptable. If the core developers would find this a useful enhancement, I would consider spending effort in my free time in helping to convert the project. I am not going to argue all the benefits this could have. If there is significant resistance to this idea then fine. However I would like to suggest a few advantages to this: 1. better IDE integration ( via m2eclipse for example ). Load and go. The current build is definitely not load and go in all IDEs, making development and submitting patches cumbersome. 2. Attracting more interest in the project, and consequently more patches, as the artifacts would easily be published in Maven central. 3. Enhance JMeter artifact usage in external plugins for Hudson,Maven, as already stated in issue 49753. I propose the conversion could be done with a script that could be applied at a convenient time in the JMeter development cycle. So are the core JMeter developers for or against this idea? --- Disclaimer: I work at Sonatype and use JMeter in my day job. Sonatype is NOT sponsoring me to work on this idea of project conversion though.
This ought to be discussed on the developer list first. Bugzilla is not suitable as a forum for discussions, though it would be useful to record any decisions here once they have been reached.
I vote -1 Having been responsible for maintaining maven in the past for a commercial project. Maven is a huge overhead and isn't worth the hassle. The whole idea of having to change the structure of the project to fit maven is stupid. Jmeter's structure is perfectly fine as it is and doesn't need to change.
I apologize for opening the issue here first before discussing on dev list. The relevant dev list thread discussing this is here http://mail-archives.apache.org/mod_mbox/jakarta-dev/201011.mbox/%3CAANLkTi=kt8MWjLy=Lr-4L4mQ_iiiH_ihjSVYM=kmJEHg@mail.gmail.com%3E
Closing as discussion led to a NO.
[Recording some extra info for completeness] Any Maven implementation would need to allow for the following: 1) Documentation is in XML, which is processed using Velocity to create the website. A separate build using different template/macros is used to generate the help files included in the binary archive. Two of those files (functions.html and component_reference.html) are used to provide help within the application itself; this requires correlation of text anchors in the HTML with the test element names. 2) JMeter assumes that all jars are in lib/ and user.classpath or lib/ext and search_paths. The former is used for support classes only; the latter is used for JMeter plugins. 3) The release build updates the version displayed by the application to include the SVN revision. 4) Some of the test classes require a lot of setup to ensure that the classpath is correct. This is normally done by the class org.apache.jorphan.test.AllTests which finds and runs all the tests. Some tests can be run stand-alone, but many cannot at present. 5) The tar.gz and zip archives use EOL=LF and EOL=CRLF for eol=native files. Some source files need to be LF and some need to be CRLF regardless of archive type. 6) The binary release contains all the dependencies, and so requires different NOTICE and LICENSE files from the source release. 7) The tests need to be runnable with headless=true for Gump and Jenkins and other CI systems 8) As well as the unit tests, there are several script tests. One script is run both stand-alone (non-GUI) and in client-server mode, which requires starting an instance of JMeter server in parallel. Other scripts are run as necessary to test bug fixes that cannot easily be unit-tested.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2429