Parallel Maven and CMake build systems for Proton

[Phil Harvey <ph...@philharveyonline.com>]

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

[Rafael Schloming <rh...@alum.mit.edu>]

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

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

[Rob Godfrey <ro...@gmail.com>]

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

[Rob Godfrey <ro...@gmail.com>]

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 <ph...@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/
>