Apache SIS branches
The source code repository contains JDK8 and JDK9 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¶
Users who want stability are encouraged to build from the trunk. Developers who want to contribute to Apache SIS are encouraged to use the JDK8 branch for now. We plan to switch SIS development to the JDK9 branch later, but the schedule is not yet determined.
The JDK9 branch is an experimental branch for migration to Jigsaw modules. It may become the main SIS development branch later, but the schedule is not yet determined.
The JDK8 branch is the recommended development branch for now. This branch implements the interfaces defined in the GeoAPI snapshot milestones. The JDK8 branch implements the same GeoAPI interfaces than the JDK9 branch.
The trunk is a merge of the JDK8 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 JDK8 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.opengis.metadata.Metadata; // Branch-specific imports import org.opengis.feature.Feature;
Substitution for non-existent classes¶
When using a JDK9 class that does not exist on JDK8, 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 JDK9-dependent
code from the JDK8 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:
JDK8as a checkout of
JDK9as 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 JDK9 directory to the JDK8 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 JDK9 svn update cd ../JDK8 svn update svn merge ../JDK9
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 JDK9 branch."
Declaring that some changes shall not be merged¶
If a developers wants to apply some changes specific to the JDK9 platform and tells Subversion to not propagate those changes to the JDK8 branch, then the following procedure shall be applied:
- Before to apply JDK9-specific changes, merge any pending changes to the JDK8 branch.
- Apply the JDK9-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 JDK9 svn update cd ../JDK8 svn update svn merge --record-only ../JDK9 svn commit --message "Skip JDK9-specific changes."