Apache SIS branches
The source code repository contains JDK7 and JDK8 branches together with the trunk. The Apache SIS releases are created from the code on the trunk only. However the actual development often occur on a branch before to be merged to the trunk. Those branches exist in order to experiment early the new technologies — since it may impact the library design — while keeping the releases compatible with more common environments.
This page lists the Apache SIS development branches, provides some coding recommendations for making merges easier, then provides the steps to follow for performing the merges.
- The development branches
- Coding recommendations
- Performing the merges
The development branches¶
Developers are encouraged to select the first branch listed below, in that order, which meet their needs.
The JDK8 branch is the recommended development branch for developers who can use a JDK8 environment. This branch implements the interfaces defined in the GeoAPI snapshot milestones and uses some JDK8 or JDK7-specific features like:
- Syntax enhancements, mostly in exception handling (try-with-resources, multi-catches) but also on other aspects like diamond operator.
- Leveraging of new API (suppressed exceptions, file systems, fork join).
- Functional interfaces and lambda expressions.
The JDK7 branch is a merge of the JDK8 branch ported to the JDK7 platform. The JDK7 branch implements the same GeoAPI interfaces than the JDK8 branch; the only differences (apart version number) are the modifications necessary for building and running on a JDK7 platform:
- Lambda expressions replaced by anonymous classes.
- New methods on collection interfaces replaced by calls to static methods.
java.timeAPI replaced by internal placeholder classes.
The JDK7 branch should behaves in a way close to identical to the JDK8 branch, with possible variations in the following aspects:
- Usage of
java.time.format.DateTimeFormatterfor parsing and formatting ISO 8601 dates are simulated by usage of
java.text.SimpleDateFormat. Those two formatters may not have the same tolerance to inputs that deviate from the standard.
The trunk is a merge of the JDK7 branch ported to the interfaces defined by the GeoAPI stable release. This is the code which is built by the continuous integration system and deployed on the Maven repository. The main differences (apart version number) compared to the JDK7 branch are the modifications necessary for implementing an older version of the GeoAPI interfaces:
Usages of non-existent GeoAPI interfaces are replaced by direct usages of the corresponding Apache SIS implementation.
When a new revision of a standard is available, the trunk still uses the old version since the new revision is not available in GeoAPI 3.0. Sometime it results in usage of methods that are deprecated on the SIS development branches.
For security reasons and for avoiding misleading information, the following functionalities are disabled on trunk
(but are still enabled on branches as experimental features). In particular the
Supervisor.ENABLED flag controls
whether the MBeans documented in the
org.apache.sis.console package are enabled or not.
ENABLEDflag is set to
REPORT_MISSING_MODULEflag is set to
Above flag values may change in future SIS releases.
Because of changes between GeoAPI 3.0 and GeoAPI 4.0-SNAPSHOT, the following aspects need special care:
opis an instance of
PassThroughOperation, then the
if (op instanceof SingleOperation)expression evaluates to
trueon trunk but to
falseon SIS development branches.
The following recommendations aim to make the merges easier by reducing the extend of potential conflicts.
Refrain from doing massive code reformatting unless:
- the modified files do not yet exist on the other branches;
- or the modified lines are known to be identical on all active branches (merges work well in such cases);
- or the committer is willing to resolve the merge conflicts.
Isolate at the end of the imports section any import statements that are specific to a platform. This separation allows any branch to re-arrange the common import statements without generating conflicts with the platform-dependent import statements. Example:
import java.io.File; import java.util.List; import org.apache.sis.util.ArgumentChecks; // Branch-specific imports import java.util.stream.Stream;
Substitution for non-existent classes¶
When using a JDK8 class that does not exist on JDK7, define a class of the same name in a
org.apache.sis.internal sub-package with the minimal amount of needed functionalities,
provided that it can be done with reasonable effort. Otherwise just delete the JDK8-dependent
code from the JDK7 branch.
Performing the merges¶
Subversion 1.5 and later maintain a
svn:mergeinfo property which make merge operations much easier.
In order to get those merge information properly maintained, no merge operation shall be performed
with older Subversion tools.
Merging changes between two branches¶
The branches and trunk checkout directories can be located anywhere on the developer machine. The following example assumes that the current directory contains the following sub-directories:
JDK7as a checkout of
JDK8as a checkout of
However the instructions below can be adapted to different directory locations by changing
the paths given in argument to the
svn merge commands.
Assuming that the developer wants to merge the changes from the JDK8 directory to the JDK7 directory,
then the following commands can be executed.
Do not specify any revision number to the
svn merge command.
Instead, let Subversion infers the proper revisions range from the
cd JDK8 svn update cd ../JDK7 svn update svn merge ../JDK8
If Subversion reports any conflicts (flagged by the
C letter before the file names),
then edit the conflicted files in any IDE and mark them as resolved:
svn resolved path/to/the/resolved/file
Clean the workspace and test the build. We suggest to execute the Maven commands in the following order,
mvn compile will find compilation problems much faster than
If any of those commands fail, edit the files at cause and re-try from the command that failed
(there is usually no need to run
mvn clean again).
mvn clean mvn compile mvn test-compile mvn install
After a successful build, commit:
svn commit --message "Merge from the JDK8 branch."
Declaring that some changes shall not be merged¶
If a developers wants to apply some changes specific to the JDK8 platform and tells Subversion to not propagate those changes to the JDK7 branch, then the following procedure shall be applied:
- Before to apply JDK8-specific changes, merge any pending changes to the JDK7 branch.
- Apply the JDK8-specific changes and commit.
- Run the following commands (edit the path arguments if the directory layout is different than the example from the previous section):
cd JDK8 svn update cd ../JDK7 svn update svn merge --record-only ../JDK8 svn commit --message "Skip JDK8-specific changes."