Hi Jeen, all,
just a quick status update:
Performed steps:
- copy src and test from original FedX repository
- code is refactored into maven standard structure
- add a basic (standalone) maven build definition
- replace license headers to RDF4J template (Thanks Jeen for the hint regarding the Eclipse tool)
- packages are adjusted to org.eclipse.rdf4j.federated.*
The build is currently basically a 1:1 translation of the Gradle script, took me a while (as I am new to maven), but seems to be working now. Next steps are obviously to integrate this into the hierarchical RDF4J build and particularly re-use the dependency definitions. I will try to do this throughout the next days, but I probably require some help here. Will come back with concrete questions or ask for help when I get stuck.
Sure thing! I have only limited time available during weekdays, but I'll do what I can.
Open questions:
- naming of main repository class: can we stick to the name FedX or do we have to use "Federated"
Keep it as-is for now, let's discuss naming later. We can always decide to change it (before there's any official release at least), but changing it back again is a little more difficult.
- do we have to provide some kind of readme with historical information
That might be useful. More generally I think we should migrate the FedX documentation to the project website, and that can include a section with a bit of history as well.
- I used the FedX project to evaluate a migration from Junit4 to Junit5 (to get a general feeling also for other projects). FedX currently uses Junit 5. Do you think it's possible to keep this in parallel to junit4 (as of RDF4J) or do I have to migrate back
I'm fine with you sticking with Junit5 - I imagine we may want to migrate the rest of rdf4j at some point as well.
We'll have to log a CQ for it though. Actually that brings up a point - we'll need to go through your (transitive) dependencies and see if there are any for which we don't have CQs yet. Probably most easily done once the maven setup is up and running.
- do we want to deprecate / remove the CLI. I would vote for yes.
You know best. Let's be conservative and deprecate for now. Any specific features we should consider porting to the Console or the Workbench?
- should I re-format the entire code? I personally always use Eclipse built-in formatter already and the code style should be pretty close.
Yes, afraid you'll have to, otherwise the build will fail. Real easy to do though: either use the Eclipse formatter with the rdf4j code conventions loaded (there's a file in /eclipse-settings), or just run `mvn formatter:format` once the code has been made part of the project.
A bit after the initial steps
- evalute potential drop-in replacement for current federation
- documentation
Anything I forgot?
If you have the chance, please have a look at the branch to get a high level impression and the direction this change goes. I am happy about any feedback.
I'll try and take a closer look later this week. I just had a quick glance though and it looks pretty good! The pom.xml will need some work to get things integrated but you're aware of that.
For the first migration you're well on track. The next step will be to evaluate which bits should be moved around, to other packages/modules. A good example are the extensions you're doing to the native store and the base sail packages - we should look into migrating those to the actual native sail and base sail modules. I reckon we should log issues for the various migrations we have in mind so we can discuss them on a case by case basis.
Cheers,
Jeen
