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.


On Fri, Feb 15, 2013 at 5:30 AM, Rob Godfrey <>wrote:

> On 15 February 2013 11:27, Rob Godfrey <> 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

Reply via email to