This is the main code repository for the Eclipse RDF4J project.
Visit the project website for news, documentation, and downloadable releases.
For installation and usage instructions of the RDF4J Workbench and Server applications, see RDF4J Server, Workbench, and Console.
For installation and usage instructions of the RDF4J Java libaries, see Programming with RDF4J.
To build the RDF4J project, including onejar and SDK files, from source, run:
`mvn -Passembly package`
(optionally add the -Pquick
flag to skip executing tests)
SDK and onejar will be available in assembly/target
. Individual module jars and wars will be in target/
in their respective modules.
We welcome contributions! Whether you have a new feature you want to add, or a bug you want to fix, or a bit of documentation you want to improve, it's all very welcome. Have a look in our issue tracker for any open problems, in particular the ones marked as good first issue or as help wanted. Or feel free to add your own new issue if what you have in mind is not there yet.
To get started on your contribution, please first read our Contributor guidelines.
The short version:
- Digitally sign the Eclipse Contributor Agreement (ECA). You can do this by logging into the Eclipse projects forge; click on "Eclipse Contributor Agreement"; and Complete the form. Be sure to use the same email address when you register for the account that you intend to use on Git commit records. See the ECA FAQ for more info.
- Create an issue in the issue tracker that describes your improvement, new feature, or bug fix - or if you're picking up an existing issue, comment on that issue that you intend to provide a solution for it.
- Fork the GitHub repository.
- Create a new branch (starting from master) for your changes. Name your branch like this:
GH-1234-short-description-here
where 1234 is the Github issue number. - Make your changes on this branch. Apply the rdf4j code formatting guidelines. Don't forget to include unit tests.
- sign off every commit (using the
-s
flag). - Run
mvn verify
from the project root to make sure all tests succeed (both your own new ones, and existing). - Use meaningful commit messages and include the issue number in each commit message.
- Once your fix is complete, put it up for review by opening a Pull Request against the master branch in the central Github repository. If you have a lot of commits on your PR, make sure to squash your commits.
These steps are explained in more detail in the Contributor guidelines.
You can find more detailed information about our development and release processes in the Developer Workflow and Project Management documentation.