-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update to jena 4.10.0 (without osgi) #196
Conversation
Thank you. Allowed GitHub Actions to run, waiting for the build. There's a current Jena 5 RC vote open too, I think (or it might have been released recently). So would be good to check if we can bump it up to 5.x at some point too. Cheers |
This PR breaks the build. We would need to bump the Java requirement for this project from Java 8 to 11. This is not something we can decide here, it needs to be brought up on the dev mailing list. |
Good point, @garydgregory . From commons-rdf readme,
Jena, from what I remember, updates JVM versions faster than Commons components (cannot remember if it's the last three version, three years? @afs ). Maybe commons-rdf will have to break away from other Commons components, and use the lowest version of the JVM that works with the latest supported version of the libraries it wants to interface with. +1 to the mailing list discussion 👍 |
Jena provides an artifact for an implementation RDF Commons that in included in every Jena release. It does this to ensure there is a jena-version-aligned implementation. https://repo1.maven.org/maven2/org/apache/jena/jena-commonsrdf/ |
The Jena project policy is "2 LTS". Jena 4.x requires Java11; Jena 5.x requires Java17. While free support for Java8 is available in some distributions (October 2026 for Eclipse Temurin) it is not universal. From the Jena's project experience, bugs are not all backported, only major ones and security related ones. As a project Jena, isn't in a position to have multiple release branches without addition active contribution for that task. Restricting to Java8 would probably discourage contributors. See also Jena Security Advisories. |
@afs Hm, the trouble started when I replaced TDB1 with TDB2. That was the reason for this PR. |
I don't have the background here. What trouble? |
@afs |
I have now tried to recreate the example: package com.example;
import java.util.UUID;
import org.apache.commons.rdf.api.Graph;
import org.apache.commons.rdf.api.IRI;
import org.apache.commons.rdf.api.RDF;
import org.apache.commons.rdf.jena.JenaGraph;
import org.apache.commons.rdf.jena.JenaRDF;
import org.apache.jena.query.ReadWrite;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.tdb.TDBFactory;
public class Test {
public static void main(String[] args) {
org.apache.jena.query.Dataset jenaDataset = TDBFactory.createDataset("target/test");
RDF rdf = new JenaRDF();
IRI namePredicate = rdf.createIRI("https://schema.org/name");
String graphNameAsString = "http://example.com/myGraph";
IRI myGraphNameAsIri = rdf.createIRI(graphNameAsString);
// READ TDB dataset
Graph myCommonsGraph4Read = ((JenaRDF)rdf).asDataset(jenaDataset).getGraph(myGraphNameAsIri).orElseThrow(()->new IllegalStateException());
myCommonsGraph4Read.stream().forEach(quad->System.out.println("commonsQuad: " + quad));
// Write TDB dataset
jenaDataset.begin(ReadWrite.WRITE);
Graph commonsRdfGraph4Write = ((JenaRDF)rdf).asDataset(jenaDataset).getGraph(myGraphNameAsIri).orElseThrow(()->new IllegalStateException());
IRI randomSubject = rdf.createIRI("http://example.com/"+ UUID.randomUUID().toString());
commonsRdfGraph4Write.add(randomSubject, namePredicate, rdf.createLiteral("Bob"));
Model jenaModel = ((JenaGraph)commonsRdfGraph4Write).asJenaModel();
jenaDataset.addNamedModel(graphNameAsString, jenaModel);
jenaDataset.commit();
jenaDataset.end();
}
} <dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-rdf-api</artifactId>
<version>0.5.0</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-rdf-jena</artifactId>
<version>0.5.0</version>
</dependency>
</dependencies> And i was not able to handle the dependencies to upgrade to |
I am beginning to understand. <dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-commonsrdf</artifactId>
<version>4.10.0</version>
</dependency> is the jena "answer" for: <dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-rdf-jena</artifactId>
<version>0.5.0</version>
</dependency> Do I understand correctly that it would be better to do without |
Yes. The dependency tree of current Jena development:
|
|
first attempts with |
RDF4J 4.0.0 -> Update to Java 11 as the minimally-required version of Java. |
currently using a custom rdf4j implementation |
Hi there,
i think I would like to use commons-rdf, but not with the old Jena version. So here is a PR for a new version. I have no idea about osgi and jena doesn't seem to support it anymore. so I just used the non osgi dependency.