Split RDF4J Project

[catch-point]

Split RDF4J Project into the following

• /eclipse/rdf4j rio, repository-api, and http client
• /eclipse/rdf4j-storage repository-sail, and all sail impls
• /eclipse/rdf4j-tools server, workbench, console, runtime, bom, assembly
• /eclipse/rdf4j-testsuite benchmark and testsuites
• /eclipse/rdf4j-doc remains the home of documentation guides

[ansell]

Great idea btw. Just wondering, will concurrent releases of all of the RDF4J artifacts still be made?

[jgrzebyta]

@jamesrdf From the practical point of view today all parts are just forks of the same repository. For example code for server exists in all repositories but only one is still actively developed. Is it planned to clean the code - remove all undeveloped code from the parts? If so do you have any "scenario"/recommendations/plan for the cleaning?

By scenario I mean giving response to following questions:

• How to solve opened issues in rdf4j if they do not fit the new content?
  • solve and remove the code vs reopen issue in the new place
• How to solve PRs?
  • merge PR and remove the code vs reopen PR in the new place
• What about if a PR affects another PR?
• If I want to clean some part of code than what should I do?
  • create new PR from develop branch
  • follow your branch issues/#915

[catch-point]

Great question!

The develop branch of /eclipse/rdf4j, /eclipse/rdf4j-storage, /eclipse/rdf4j-tools, and /eclipse/rdf4j-testsuite don't overlap with one another. For any 2.3 code changes these develop branches for the corresponding github project is to be used.

We will use /eclipse/rdf4j/tree/master for any 2.2.x code changes until 2.3 is released in the new year. The master branch of storage/tools/testsuites should not be modified (or used) in any way until after 2.3 is released.

Once 2.3 is released the develop branch of all these github projects will be copied to their master branches and used for any 2.3.x patch releases.

New issues and new pull-requests for 2.3 should be created in a corresponding github project. No need to close/reopen issues, instead reference existing issues/PRs from /eclipse/rdf4j using the cross referencing syntax: https://help.github.com/articles/autolinked-references-and-urls/

2.2.x shouldn't have much changes before 2.3 is released, so I don't expect porting 2.2.x PRs to 2.3 to be much of an issue. However, contributors will have to be careful to target their PRs to the develop branch of the correct github project!

There will be some scenarios that require changes to multiple github projects, which will require multiple PRs, which will have to be merged in the correct order to ensure the build does not break in the process.

To contribute checkout the develop branch of one (or more) of the github projects and have at it. This issue has been resolved for 2.3 codebase, so no need to follow any special branches (just their develop branches).