This page lists the proposals that have been discussed on the Proton mailing list to meet the requirements on Proton build system requirements.

Each section describes potential requirements that are not met by the proposal.

SVN externals

Description: use SVN's "svn:external" metadata to link from proton-c/bindings/java/ to proton-j/proton-api.

Issues:

  • "To switch to a particular SVN revision, simple SVN commands are run". This process is error-prone when using SVN externals.

proton-api duplicated under proton-c

Description: a copy of proton-api would be checked in under proton-c, making it possible to build a standalone checkout of proton-c. A script would be run at proton-c build time to report an error if differences are found between the two copies.

Issues:

  • "To change proton-api, all that is required is to edit a Java file". When changing the proton-api, a developer would need to remember to perform whatever steps are necessary to bring the two copies in line with each other.  These steps would need to be implemented in a foolproof and platform-neutral manner.

Make proton-c treat proton-api as an external dependency

Description: if we follow this proposal, the source code of proton-api will no longer be duplicated in proton-c. Instead, proton-c will treat proton-api as a build-time dependency, as originally proposed on the Proton mailing list discusion. 

Issues:

  • "A tarball source release of proton-c can be built by a user without an external dependency on any other part of proton".  The release script would have to copy proton-api into the tar file.
    • This release-time copying violates the requirement that the release tarball is produced by a simple "svn export". When building the released tarball, the proton-c build script would need to build the bundled proton-api source rather than treating it as an external dependency.
  • Otherwise, the user would avoid this problem by either downloading the source tarball for the whole proton project (possibly with an option to omit the proton-j implementation), or would download the proton-api binary from a Maven repository.
  • "proton-c can be built without requiring non-standard tools."  The developer would check out the top-level proton project and use Maven build proton-api, as an upstream dependency of proton-c's JNI bindings.

Augmenting Python system tests with Java JUnit tests

This proposal is not mutually exclusive with respect to the other ones but is worth mentioning here.  Work is ongoing to augment the Python system tests with Java JUnit ones under the same folder. Maven is used to run the full Python and Java suite.

Issues:

  • "proton-c can be tested without requiring non-standard tools".  The Python tests can be run manually if desired, i.e. without invoking Java or Maven, but Maven is required in order to include the Java tests.
  • No labels

2 Comments

  1. Gordon Sim

    Suggested alternatives (I have not pursued these in detail to see whether there are issues preventing them being implemented):

    • have JNI binding as a distinct component dependent on both the pure java proton library and the c proton library
    • have two parallel build systems - e.g. mvn & cmake/make - that can each detect the availability of requisite tools (javac, gcc, swig etc) and build only those components that the available tools enable (windows may be more problematic here since cmake creates a visual studio project file I believe which may be less flexible than make).

    1. Rob Godfrey

      If I follow Gordon's second suggestion correctly this would mean we would have two distinct build systems that you can initiate from the top level of the proton tree.

      Then, from the top level directory we could do

      mvn package

      or mkdir build ; cd build ; cmake .. ; make

      to build the Java or C components respectively. In the second case this would include the JNI binding.

      I'm quite fond of this as a proposal. To my mind it also makes the preparation of source tarballs that are strict subsets of the proton source tree easier. To release a C source tarball we would simply tar up the proton-c, test and proton-j/proton-api directories (excluding all the pure java implementation sources). To produce a Java source tarball we would tar up the proton-j and test directories.