We are also still on TDB 1 with our product. Needs some research on our side to judge on the impact.
Holger > On May 14, 2025, at 09:19, Dave Reynolds <dave.e.reyno...@gmail.com> wrote: > > > On 13/05/2025 14:08, Soroka, Adam wrote: >> Should we also consider retiring TDB 1 at this point if we’re looking for >> other modules that get little attention or are outdated? > > We, at least, are completely dependent on TDB 1. We've never managed to tame > the memory use growth in TDB2 enough to use it in production. > > To be fair, it's been a while since we last tried. > > Dave > >> +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? >
