Should we also consider retiring TDB 1 at this point if we’re looking for other
modules that get little attention or are outdated?
+1, for the reasons Rob gave. I'm not sure how deep our expertise is for TDB1,
as well.
Adam Soroka
Office of Data Platforms and Advanced Computing / Office of Digital
Transformation
Smithsonian Institution
________________________________
From: Rob @ DNR <rve...@dotnetrdf.org>
Sent: Tuesday, May 13, 2025 5:07 AM
To: dev@jena.apache.org <dev@jena.apache.org>
Subject: Re: Jena 6
External Email - Exercise Caution
Re: Removing initialBindings support
While this is not a feature I’ve ever used, nor would I recommend to anyone, it
is a longstanding feature, and I remember a previous effort to remove it some
years ago (Jena 4 maybe?) got a lot of push-back within the Jena community.
I think it is indeed time for this feature to be permanently removed but it may
be worth sending an explicit message about the planned removal, and migration
paths, to the users list now in addition to marking it for deprecation (which
it already has been for some time).
That way when we get the inevitable “You removed X” complaints when Jena 6
comes out (because even with deprecation markers and advance notice some users
will still keep using the API) we can point to that message, and the code
history, and say “You knew this was coming and we gave you ample notice to
migrate” and stand firm on not restoring it as I believe we had to do previously
Re: Module retirements
Should we also consider retiring TDB 1 at this point if we’re looking for other
modules that get little attention or are outdated?
While it is also a very longstanding feature of the project TDB 2 is generally
preferable for most use cases, and we already have limited volunteer bandwidth
to manage many modules and try to keep up with evolving W3C standards per our
Project Charter.
Rob
From: Andy Seaborne <a...@apache.org>
Date: Saturday, 3 May 2025 at 16:18
To: dev@jena.apache.org <dev@jena.apache.org>
Subject: Jena 6
Java25 is LTS and due September 2025.
Jena moved forward at Java17 and at Java21 with a major release to keep
the supported JDKs at "the last two LTS" when it's clear that the LTS
has no major problems.
A consequence this time is that Jena can update to depend on Lucene 10,
which requires Java21.
== Java 21
== More RDF 1.2 / SPARQL 1.2
== Lucene 10 dependency update
== jena-iri3986 switch over
* jena-iri3986 as IRIx provider.
== Retire module jena-iri
== retire ARP (some more)
ARP0 is the original ARP that uses jena-iri directly.
ARP1 is ARP updated to use IRIx
Remove the ARP0 codebase.
Move ARP1 to src/test/ for test support.
There is an old Turtle parser already for test support.
? Move the RDF/XML writer to RIOT.
This means jena-core does not have RDF/XML input on it's own.
== jena-ontapi
Should we remove old "ont" from jena-core in favour of jena-ontapi?
A blocker here might be whether jena-ontapi has support
for Jena assemblers.
== Remove ARQ "initial binding"
Prefer "substitution" which applies uniformly to
local and remote queries.
== Remove @Deprecated code
Specifically code related to "initial binding" in ARQ.
== And also?
