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.com>wrote: > 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 >
