[CONF] Apache Qpid > Java Build System

[Phil Harvey (Confluence)]

Java Build System Page edited by Phil Harvey Changes (1) ... * Java compiler version (v1.6) etc h3. Define what the maven modules should be and what their dependency relationships are These are likely to be slightly different to the existing modules. h3. Add pom.xml files to existing module folders * The build.xml files would not be removed until the refactoring is complete. ... Full Content This page describes how we would replace the Qpid Java Ant-based build system with one that uses Maven. The intention is to establish what we would need to do. Debate about whether it's actually worth doing should take place on the mailing list(s). Tasks Define what the build system has to do Add top-level pom.xml in qpid/java/ Define what the maven modules should be and what their dependency relationships are Add pom.xml files to existing module folders Get systests working Execute code generation in the same way as today Tasks The likely steps are listed in the sections below. Define what the build system has to do This is important so we can check how close to complete we are as we progress. To be included: Full set of artifacts, e.g. *.tar.gz files The tests that should be run The reports that should be generated, e.g. test results, code coverage reports etc. Define how custom builds will be supported. For example, if an organisation wishes to produce a custom Qpid build including third-party broker plugins, how will this be achieved? Add top-level pom.xml in qpid/java/ Use this to define things such as: Set of modules to be built Java compiler version (v1.6) etc Define what the maven modules should be and what their dependency relationships are These are likely to be slightly different to the existing modules. Add pom.xml files to existing module folders The build.xml files would not be removed until the refactoring is complete. The dependencies should be quite easy to set up, using the information already in build.deps. Get systests working The compile-time dependency from systests to the test code of other modules can be easily satisfied - proton's test module already does this. Replace the existing "profiles". Maven's profiles can probably be used to do this. Specifically: Each profile could specify some JUnit Categories to include/exclude in the tests Each profile could set the required system properties. Given that Maven profiles are not mutually exclusive, we could create specific profiles for each "dimension" (e.g. store type protocol version, whether to spawn the test broker) and activate several of them at run-time.** Execute code generation in the same way as today This is used to generate logging code and protocol-specific code. We will probably have to launch external tools such as Velocity and Jython using Maven's built-in mechanism. Stop watching space | Change email notification preferences View Online | View Changes | Add Comment --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@qpid.apache.org For additional commands, e-mail: commits-h...@qpid.apache.org