We are currently in the process of implementing the proton-jni binding
for the proton-c library that implements the Java Proton-API, allow
Java users to choose the C based proton stack if they wish. This work
is being performed on the jni-branch under PROTON-192 (for the JNI
work) and PROTON-194 (for the build system changes).

Currently, Proton has two independent build systems: one for the
proton-c and its ruby/perl/python/php bindings (based on Cmake/Make),
and second a separate build system for proton-j (based on Maven).  As
proton-jni will cut across both technology areas, non trivial changes
are required to both build systems.

The nub of the problem is the sharing of the Java Proton-API between
both proton-c and proton-j trees. Solutions based on svn-external and
a simple tree copy have been considered and discussed at length on
conference calls.  We have identified drawbacks in both solutions.

This email proposes another solution. The hope is that this proposal
can be developed on list into a solution that is acceptable to all.


Move the Java Proton-API to the top level so that it can be shared
simply and conveniently by both proton-j and proton-c.

* Maven builds the proton-api JAR to a well known location
* Cmake/make builds proton-c and all bindings including java. As the
building of the java binding requires the Java Proton API, it is
optional and only takes place if proton-api has been previously
created by Maven (or found by other means).
* Maven builds of proton-j
* Maven runs the system tests against either proton-c or proton-j. The
system tests are currently written in Python but are being augmented
with new ones written in Java.

Proposed Directory Structure:

|-- release.sh/bat                  # Builds, tests and packages
proton-c and proton-j
|-- pom.xml
|-- proton-api                      # Java Proton-API
|   |-- pom.xml                     # Will create proton-api.jar at a
well known location in tree
|       `-- main
|-- proton-c                        # Proton-C and Proton-C bindings
|   |-- CMakeLists.txt
|   `-- bindings
|       |-- CMakeLists.txt
|       `-- java
|           |-- CMakeLists.txt
|           `-- jni
|               `-- CMakeLists.txt  # Creates proton-jni.jar using
proton-api.jar from a well known
|                                   # location in tree or skip if jar
cannot be found
|-- proton-j                        # Proton-J
|   |-- pom.xml                     # Creates proton-j.jar using
proton-api.jar (found via Maven)
|   `-- src
|       `-- main
`-- tests                           # Python and Java based system
tests that test equally Proton-C and
    |                               # Proton-J.
    |-- pom.xml
    `-- src
        `-- test

Use cases:

usecase #1 - Proton-C Developer exclusively focused on Proton-C

This developer may choose to check out the proton-c subtree.  The
build tool set remains unchanged from today i.e. cmake and make.  By
default, all bindings will be built expect for the java bindings (as
Cmake would fail to find the proton-api.jar).  For flexibility, we
would include option to have cmake search another directory allowing
proton-api.jar to be found in non-standard locations.

usecase #2 - Proton-C Developer who wishes to run all system tests

This developer must check out the complete proton tree.  The build
tool set now includes maven in order to build the proton-api and run
the complete system test suite.

Typical commands used by this developer would be:
mvn -f proton-api/pom.xml install  # build and install proton-api to
the well known location
<build proton-c>
mvn test                           # run all the system tests against proton-c.

usecase #3 - Proton-J Developer

This developer must check out the complete proton tree.   The build
tool set is maven.

mvn test -Pproton-j                # build all and run the system
tests against proton-j (the -P switch to specifies the Maven profile
to use)

usecase #4 - Release manager

The release manager must check out the complete proton tree.  The tool
set will be maven, cmake, make in order to build and test all
artefacts. A release script could be added to make this a single step.


Reply via email to