Parallel Maven and CMake build systems for Proton
During the review [1] of PROTON-238, Alan made the following, not-entirely-unreasonable-sounding comment: Having 2 parllel build systems is a serious pain, as qpid demonstrates. Wouldn't it be better to leave maven for Java and cmake for everything else? People who want to build Java probably can get maven. (Alan: please forgive me if I've taken this of context) I don't particularly want to open this can of worms again, but I think it is worth addressing this question. I believe the conclusions we reached in PROTON-194 were: - Our CMake build system will be capable of building and testing everything (both C and Java). It is required because some users who wish to build Proton don't have Maven access. - Our Maven build system will be retained because it is a more standard build tool for Java developers. I acknowledge that maintaining both build systems is an annoying duplication of effort. However, our requirements are to provide a convenient build system for all our users so we have no choice. Please shout if you disagree. Phil [1] https://reviews.apache.org/r/9433/
Re: Parallel Maven and CMake build systems for Proton
A few of supplementary points: 1) The CMake system will not be required to generate pom files or deploy to maven repositories. 2) The CMake system will not be required to perform dynamic dependency resolution 3) The CMake system will not be required to integrate with other build/test tooling (coverage reports, style checkers, etc) which may be provided within the maven build system I'm also not sure exactly how well the CMake build system will work with the Java build on Windows systems (my guess would be not well)... we should probably look to make it work if we can, but this may not be trivial. -- Rob On 15 February 2013 11:03, Phil Harvey p...@philharveyonline.com wrote: During the review [1] of PROTON-238, Alan made the following, not-entirely-unreasonable-sounding comment: Having 2 parllel build systems is a serious pain, as qpid demonstrates. Wouldn't it be better to leave maven for Java and cmake for everything else? People who want to build Java probably can get maven. (Alan: please forgive me if I've taken this of context) I don't particularly want to open this can of worms again, but I think it is worth addressing this question. I believe the conclusions we reached in PROTON-194 were: - Our CMake build system will be capable of building and testing everything (both C and Java). It is required because some users who wish to build Proton don't have Maven access. - Our Maven build system will be retained because it is a more standard build tool for Java developers. I acknowledge that maintaining both build systems is an annoying duplication of effort. However, our requirements are to provide a convenient build system for all our users so we have no choice. Please shout if you disagree. Phil [1] https://reviews.apache.org/r/9433/
Re: Parallel Maven and CMake build systems for Proton
On 15 February 2013 11:27, Rob Godfrey rob.j.godf...@gmail.com wrote: 2) The CMake system will not be required to perform dynamic dependency resolution I should probably have phrased that one better... What I meant is that (unlike maven) we're not looking for the CMake build to go and find JARs, resolve transient dependencies, and download to the machine you are building on. -- Rob
Re: Parallel Maven and CMake build systems for Proton
This is certainly somewhat more contained that what the qpid broker tree has done. It's not quite two parallel build systems, but more two separate build systems that happen to work on overlapping source trees. The cmake build system covering the whole source tree (C, C++, Python, PHP, Ruby, Perl, and JNI+Java), and the maven build system covering only the pure java subset of the tree. They aren't really parallel, however as they don't need to work in the same way or conform to the same interface. They can both work in whatever way is most natural to them. The only place they are wed together is in sharing a common source layout for the pure Java portion of the tree. Given this, I think it's a manageable situation, and there are good (or at least unavoidable) reasons to do this, namely we need to deliver maven binaries for the pure Java code regardless and we also need the cmake build to be able to build Java for the JNI binding. The workability of this solution, however, depends on a fairly well defined and contained portion of overlapping source code that contains pretty much just vanilla Java code, e.g. if the pure Java code that needs to be visible to both the cmake and maven builds keeps sprouting new arms and legs each of which depends on a new maven plugin that needs to be replicated in the cmake build, then there is obviously going to be more possibility for broken builds. Fortunately I think it's very consistent with the goals of the project for the overlap to be a very well defined/contained set of code, but it's probably worth stating this requirement on the source tree up front regardless. In particular it's also worth noting that this may have implications for how we want handle contrib type stuff that shows up in pure Java land. --Rafael On Fri, Feb 15, 2013 at 5:30 AM, Rob Godfrey rob.j.godf...@gmail.comwrote: On 15 February 2013 11:27, Rob Godfrey rob.j.godf...@gmail.com wrote: 2) The CMake system will not be required to perform dynamic dependency resolution I should probably have phrased that one better... What I meant is that (unlike maven) we're not looking for the CMake build to go and find JARs, resolve transient dependencies, and download to the machine you are building on. -- Rob