Re: [rdf4j-dev] Split RDF4J Project

[Jacek Grzebyta <grzebyta.dev@xxxxxxxxx>]

Hi James,

I see problems related with the existence of large number of modules. But also there are some problems related with that.

I have two questions regarding the proposition:

On 28 August 2017 at 14:39, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:

Hi all,

I'd like to split the main github project into a four smaller ones.

RDF4J is already separated into modules. However, any small change
takes time to go through verification stages. This creates a barrier to
entry for contributions that encourages shortcuts. Currently it takes
over an hour to verify the distribution. By splitting the project up
the verification phase can be more focused and modular.

I propose the following setup:

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

I imagine the new 'units' would be treated as git submodules (see https://git-scm.com/book/en/v2/Git-Tools-Submodules) rather than java-level modules (Am I right?)  so I suggest "/rdf4j" unit would be the main repository - that one with .gitmodules file. If so I guess there should be a separate "policy of changes" for that.

The role of that module would be to simplify of the whole project compilation. I think client, server and http might be deeply related with bunch of another modules (risk of spaghetti???) so IMHO they should be kept in the same unit.

 

Compliance tests would be split up into the corresponding module. Each
github project would be a fork of the current and each would have
master/develop branches and each would be setup to be built nightly.

Issues and Pull-Requests would also be separated, but github allows
referencing issues and PRs in separate projects to aid with
integration.

All java modules has dedicated integration test within the testsuit. Usually they all kept in the same PR. If we separate the code changes from the integration tests how to relate at least two PRs (3 PRs are for a combination: code+testsuit+documentation)?

Regards,

Jacek