The next questions to be clarified are of technical nature:
* Would FedX become its own module / artifact within the RDF4J project. Suggestion: yes
This seems the most natural choice, at least for the first migration. However I would suggest that it might make sense to refactor/break it up later on. As an example: it seems logical to me to take the FedXRepository implementation and make it its own module alongside SailRepository and other Repository API implementations. But as said let's bring the code into the project as one big module first, and then consider further.
* Where (which repository) would we check-in the code. We might need a fresh repository
Unless you have strong objections I would be in favour of making it part of the main rdf4j code repository. There are significant advantages to having the entire code base in a single repo. Initially, the best place is probably in the tools/ directory, as a module alongside the console, the workbench, and the rdf4j server.
* Regarding code structure: we might probably need to change all package names, as well as license headers. Are there any guidelines for this?
There are some simple guidelines, like the root of the package name should be org.eclipse.rdf4j. Where we put it below that is up for grabs. I don't know if we want to stick with the name FedX (or even if we can). Perhaps for now we simply go with org.eclipse.rdf4j.federated as a package name? That also means some class names get changed, e.g. FedXRepository would become FederatedRepository.
Finally: I've noticed FedX is set up as a gradle project. If we make it part of rdf4j we will have to migrate it to maven. Happy to help with the setup for that of course.
Do you have any comments or suggestions?
I think we also have to have a think about what to do with the existing FederationSail. As I understand it, it's pretty much made obsolete by the more advanced federation capabilities of FedX. Should we mark it deprecated? Or can we even just completely replace the existing FederationSail with the more advanced FedX implementation in a backward-compatible way?
Of course I'm happy to help with the work where necessary! I suggest the easiest practical way forward is that you start refactoring on a branch in your own repo: do the package renaming and license replacements there. Once it looks good, copy it over to the rdf4j repo (on a feature branch), in a directory under tools (tools/federated will do at first, we can always rename). Don't worry too much about preserving commit history. Push and put up a PR (against the develop branch), and then let's see what we've got :)
Cheers,
Jeen
