Re: [VOTE] Apache Jena 3.16.0 RC 1
[X] +1 Approve the release Built from git tag on OS X with Java version 1.8.0_231 Deploys into Karaf 4.2.8 (OSGi) Works with Java Platform Module System (Java 11) Hashes and Signatures are all good LICENSE and NOTICE files are present Thanks for preparing this release. Cheers, Aaron On Thu, 9 Jul 2020 at 14:49, Andy Seaborne wrote: > Hi, > > Here is a vote on the release of Apache Jena 3.16.0 > This is the first proposed release candidate. > > The deadline is Monday, 13th July 2020 at 12:00 UTC > > Dependency changes: > > JENA-1896 : Update shaded Google Guava to 29.0-jre > > Changes for 3.16.0: > > https://s.apache.org/jena-3.16.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachejena-1039 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/c78176284b > > Git Commit Hash: >c78176284b89c00fff929cd18e15e2b704991887 > > Git Commit Tag: >jena-3.16.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open until at least > > Monday, 13th July 2020 at 12:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > >Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive really be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: Towards 3.17.0
This looks excellent. Should we also update the version of o.a.httpcomponents:httpclient? 4.5.10 => 4.5.13 Aaron On Tue, 10 Nov 2020 at 15:21, Bruno P. Kinoshita wrote: > Looks good to me. I thought there would be 5-10 issues, was surprised to > see 38! Great work, +1 > Bruno > > On Wednesday, 11 November 2020, 6:30:55 am NZDT, Andy Seaborne < > a...@apache.org> wrote: > > Jena 3.16.0 was 2020-07-09 > so the tick for 3.17.0 is here. > > There's a list of notable items below - is anything missing? > > Tickets this release: > https://s.apache.org/jena-3.17.0-jira > > Also of of note: > ## Proposal: > Didac: Titanium proposal for JSON-LD 1.1 > No changes in this version. > Discuss! > > > Andy > > > ## Work-in-progress: > > JENA-1911: Updating Fuseki UI > JENA-1894: Order preserving datasets > JENA-1987: Add Fuseki /$/compact/* endpoint > JENA-1992: Fix for logging running in Tomcat. > > ## Updates: > JENA-1959, JENA-1967 > JSON-LD 0.12.5 -> 0.13.2 (umbreak) > JENA-1972: Jetty 9.4.26 -> 9.4.31 > JENA-1973: Micrometer: 1.2.1 -> 1.5.5 > JENA-1992: Update Log4j2 to 2.14.0 > JENA-1993: Update Eclipse Jetty to 9.4.34 > > ## > ## Features: > > JENA-1982. SPARQL \U escapes in String and IRIs. > This is a change to ARQ extended SPARQL syntax. > > Pavel Mikhailovskii > > JENA-1950: Use GraalVM for javascript if available. > This also opens up the possibility of other languages for scripting > SPARQL extension functions. (JENA-1951) > > The license means we do not ship GraalVM itself (and it is quite big). > > JENA-1968 > Support Turtle output with relative URIs but no BASE declaration. > > JENA-1974: G library > A library for working with Graphs > More : > > https://lists.apache.org/thread.html/r973fd076583327b75e15bda798dce66d47f4f7cd8dbaa14c280f1fe3%40%3Cdev.jena.apache.org%3E > > JENA-1937: SHACL Compact Syntax writer > > > Fuseki: > > JENA-1929: Fuseki: Detect TDB1/TDB2 database types. > > JENA-1949: Dockerfile > and build instructions > https://jena.apache.org/documentation/fuseki2/fuseki-docker.html > > This is a build system published as a zip file and it can be used to > build a docker container (about 100M) for any recent version of > Fuseki/Main. > > JENA-1976 > Make CORS support in Fuseki main default to on. > > JENA-1961 > Support /$/metrics in Fuseki Main > > JENA-1989 > Logging in Fuseki/webapp > >
Re: dependabot results and
Thanks, that was a bit of work from a question about just one dependency, but hopefully this will make maintenance quite a lot easier going forward. Aaron On Thu, Nov 12, 2020, 12:54 Andy Seaborne wrote: > OK - I think it is tamed for now! > > A lot of updates, nothing serious showing up. The build became unstable > due to trying to do too much in one go but should now be green - it is > at TravisCI. > > Andy > > == Process > > dependabot is administered by the file > > /.github/dependabot.yml > > Currently, set to run monthly. > > There is no other setting for on/off; if it is there, dependabot runs > > This is not all good; it runs for clones of the repo but they don't any > tidy and suppression of unwanted updates. > > The "schedule" is required otherwise it could be manual and run from GH > UI via "Insights" -> "Dependency Graph" -> "Dependabot". > > == This cycle > > There are a couple for major upgrades highlighted: > > * Lucene 7 -> 8 > * org.osgi.core 5.0.0 -> 6.0.0 > > (nothing done about them) > > Too near to a release for org.osgi.core and Lucene 7->8 is a major > decision and there is no rush that I'm aware of. > > * jena-elephas : Uses hadoop 2, guava 11 - I hope I've told the > dependabot to ignore these. > > It's the Guava bit that I'm unsure about as we have two different > dependencies. > > == Things that broke: > > GeoSPARQL > SIS 0.8 -> 1.0 : test failure > (left at 0.8, JENA-1996) > > jena-sdb : hsql v2 >Left at v1 > > == Notes > > 1/ > Derby 10.15.x.y requires java9, so updated only as far as 10.14.x.y and > then dependabot asked to ignore the minor version. > (used for testing by jena-sdb by jena-geosparql) > > 2/ > The updated shade plugin has some new warnings about overlapping files. > It looks safe, needs checking (and maybe there are shading transformers > to merge the files). > > > == Updates done > > HttpClient to 4.5.13 > commons-lang3 from 3.10 to 3.11 > guava 29-jre to 30-jre (shaded) > spatial4j from 0.6 to 0.7 > airline.version from 2.1.1 to 2.8.0 > jts-core from 1.16.1 to 1.17.1 > shiro from 1.5.1 to 1.7.0 > jackson from 2.10.1 to 2.11.3 > commons-codec 1.14 to 1.15 > commons-io from 2.6 to 2.8.0 > micrometer from 1.5.5 to 1.6.1 > jcommander from 1.72 to 1.78 > > and plugins. > > Andy >
Re: dependabot results
> BTW was there a particular fix in HttpClient 4.5.13 that you wanted? > There is a CVE for HttpClient before 4.5.13 related to a malformed authority component https://mail-archives.apache.org/mod_mbox/hc-httpclient-users/202010.mbox/%3C4202d88eabd0ad2a0287243b281cad1bd2b9b141.camel%40apache.org%3E > Elsewhere [*], I have been through all the HTTP APIs in Jena, which have > lots of history, restructured them to update the style (e.g. > QueryExecutionHttp.Builder) > > > It's java11 use java.net.http which I found to be easy to use. It has > async support and internally it is truly async I/O inside. > > Andy > > [*] https://github.com/afs/jena-http > > > but hopefully this will make maintenance quite a lot easier going > forward. > > > > Aaron > > > > On Thu, Nov 12, 2020, 12:54 Andy Seaborne wrote: > > > >> OK - I think it is tamed for now! > >> > >> A lot of updates, nothing serious showing up. The build became unstable > >> due to trying to do too much in one go but should now be green - it is > >> at TravisCI. > >> > >> Andy > >> > >> == Process > >> > >> dependabot is administered by the file > >> > >> /.github/dependabot.yml > >> > >> Currently, set to run monthly. > >> > >> There is no other setting for on/off; if it is there, dependabot runs > >> > >> This is not all good; it runs for clones of the repo but they don't any > >> tidy and suppression of unwanted updates. > >> > >> The "schedule" is required otherwise it could be manual and run from GH > >> UI via "Insights" -> "Dependency Graph" -> "Dependabot". > >> > >> == This cycle > >> > >> There are a couple for major upgrades highlighted: > >> > >> * Lucene 7 -> 8 > >> * org.osgi.core 5.0.0 -> 6.0.0 > >> > >> (nothing done about them) > >> > >> Too near to a release for org.osgi.core and Lucene 7->8 is a major > >> decision and there is no rush that I'm aware of. > >> > >> * jena-elephas : Uses hadoop 2, guava 11 - I hope I've told the > >> dependabot to ignore these. > >> > >> It's the Guava bit that I'm unsure about as we have two different > >> dependencies. > >> > >> == Things that broke: > >> > >> GeoSPARQL > >> SIS 0.8 -> 1.0 : test failure > >> (left at 0.8, JENA-1996) > >> > >> jena-sdb : hsql v2 > >> Left at v1 > >> > >> == Notes > >> > >> 1/ > >> Derby 10.15.x.y requires java9, so updated only as far as 10.14.x.y and > >> then dependabot asked to ignore the minor version. > >> (used for testing by jena-sdb by jena-geosparql) > >> > >> 2/ > >> The updated shade plugin has some new warnings about overlapping files. > >> It looks safe, needs checking (and maybe there are shading transformers > >> to merge the files). > >> > >> > >> == Updates done > >> > >> HttpClient to 4.5.13 > >> commons-lang3 from 3.10 to 3.11 > >> guava 29-jre to 30-jre (shaded) > >> spatial4j from 0.6 to 0.7 > >> airline.version from 2.1.1 to 2.8.0 > >> jts-core from 1.16.1 to 1.17.1 > >> shiro from 1.5.1 to 1.7.0 > >> jackson from 2.10.1 to 2.11.3 > >> commons-codec 1.14 to 1.15 > >> commons-io from 2.6 to 2.8.0 > >> micrometer from 1.5.5 to 1.6.1 > >> jcommander from 1.72 to 1.78 > >> > >> and plugins. > >> > >> Andy > >> > > >
Re: Java 8 or 11?
At this point, Java8 is no longer supported by Oracle. (OpenJDK and AWS Corretto will both continue to support security updates), and from what I've been seeing, much of the Java ecosystem is moving in this direction, too. Everything I work on uses Java 11, so I am generally +1 on moving in this direction. (The ability to use Titanium is compelling for me) The steps proposed sound very reasonable to me. Aaron On Fri, 1 Jan 2021 at 09:59, Martynas Jusevičius wrote: > I recently upgraded AtomGraph components to Java 11 and took advantage > of the -XX:MaxRAMPercentage JVM setting in a Docker setup: > https://www.eclipse.org/openj9/docs/xxinitialrampercentage/ > > On Fri, Jan 1, 2021 at 1:13 PM Andy Seaborne wrote: > > > > Should we switch to Java11? > > > > There are the usually issues of moving to a newer Java. There seems > > likely to be an emerging bimodal distribution of systems remaining with > > Java8 and systems moving to Java11 and Java 17 (likely an LTS - > > September 2021). > > > > The question is how many systems would upgrade their Jena version and > > are restricted to Java8 (and why!). > > > > Java is evolving to better fit in the new tech landscape (e.g. better > > container usage), more compact strings (significant for Jena), and > > JDK-provided HTTP/2. > > > > Some dependences or potential dependencies are Java11: > > > > Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld ) > > > > Eclipse Jetty 10 and 11 now depend on Java11. > > > > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the > > package root name "javax..." whereas Jetty11 uses package route > > "jakarta...") > > > > Proposal: > > > > 1/ Ask on users@ -- what we need is "new information" such as "I am > > blocked from updating Java because ...", not "I haven't got round to it". > > > > 2/ Switch to Java11 for the next release but not make so many changes > > that we can't easily go back to Java8. > > > > Andy >
Re: Java 8 or 11?
On Fri, 8 Jan 2021 at 14:33, Martynas Jusevičius wrote: > Suggestion: migrate builds to GitHub actions. I just did that for our > test suites. > > https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works +1 (I used travis-ci for a long time, but now I use GH actions almost exclusively) > > > On Fri, Jan 8, 2021 at 6:38 PM Andy Seaborne wrote: > > > > Status: JENA-2022 > > > > One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which > > hits a javadoc problem > > > >https://bugs.openjdk.java.net/browse/JDK-8212233 > > > > (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA > > release, or 11.0.3 or later, then 12.0.0, 12.0.1) > > > > I think this is triggered by cross links in Java source code from one > > module to another when the modules have Automatic-Module-Name. The fixes > > mentioned don't work for Jena. > > > > See also https://issues.apache.org/jira/browse/MJAVADOC-555 > > > > There are no problems building with the default Java11 on my machine > > (11.0.9) > > > > For now I have switched off javadoc production in the .travis.yml file. > > > > It should be OK on ASF Jenkins because there, we control the JDK (and > > only 11.0.9 in various forms is available anyway). > > > > What the travis file does for us is that PRs automatically get a check > > applied of running the build with the PR at travis (it can take a while > > to get scheduled and run). We didn't ask INFRA for this - recent > > infrastructure changes mean it just happens. > > > > Andy > > > > On 01/01/2021 12:13, Andy Seaborne wrote: > > > Should we switch to Java11? > > > > > > There are the usually issues of moving to a newer Java. There seems > > > likely to be an emerging bimodal distribution of systems remaining with > > > Java8 and systems moving to Java11 and Java 17 (likely an LTS - > > > September 2021). > > > > > > The question is how many systems would upgrade their Jena version and > > > are restricted to Java8 (and why!). > > > > > > Java is evolving to better fit in the new tech landscape (e.g. better > > > container usage), more compact strings (significant for Jena), and > > > JDK-provided HTTP/2. > > > > > > Some dependences or potential dependencies are Java11: > > > > > > Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld ) > > > > > > Eclipse Jetty 10 and 11 now depend on Java11. > > > > > > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the > > > package root name "javax..." whereas Jetty11 uses package route > > > "jakarta...") > > > > > > Proposal: > > > > > > 1/ Ask on users@ -- what we need is "new information" such as "I am > > > blocked from updating Java because ...", not "I haven't got round to > it". > > > > > > 2/ Switch to Java11 for the next release but not make so many changes > > > that we can't easily go back to Java8. > > > > > > Andy >
Re: [LAZY] rename default branches as 'main'.
+1 On Fri, Feb 5, 2021, 06:03 Andy Seaborne wrote: > +1 > > On 05/02/2021 10:04, Andy Seaborne wrote: > > This is a decision by lazy consensus[*]. > > > > Let's rename the default branch as 'main' for both the code repo and the > > site repo. > > > > The process is: > > > > 1/ We create a repo branch 'main' > > 2/ Ask infra to make it the default > > 3/ We remote delete 'master' > > 4/ Update build jobs in Jenkins > > 5/ Update the site build job on Jenkins > > (via the "Jenkinsfile" in the jena-site repo) > > > > and on local copies after step 2: > > > > # Rename locally > > git branch -m master main > > # Set tracked branch > > git fetch origin > > git branch -u origin/main main > > > > I think github forked repos and PRs automatically switch. > > > > Andy > > > > [*] > > Lazy Consensus: > > https://community.apache.org/committers/lazyConsensus.html > > > > Default to agree, wait 72 hours. > > but adding +1 is nice. >
Re: [] Apache Jena 4.0.0 RC 1
> The deadline is Tuesday, 30 March 2021 at 21:00 UTC > > Please vote to approve this release: > > [X] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > Built fine from the git tag with Java 11.0.10, Maven 3.6.3 on OS X Also built fine from the source distribution Signatures are all good Checksums are all good OSGi deployment in Karaf (and tests with PaxExam) works well I have also tested this RC with some downstream applications, and everything checks out: the upgrade was just a matter of changing the maven coordinates Thanks, Andy, for the work to prepare this release. -Aaron
Re: [DRAFT] Apache Jena report (April 2021)
+1 Thanks for preparing the report On Wed, 7 Apr 2021 at 10:25, Andy Seaborne wrote: > ## Description: > The mission of Jena is the creation and maintenance of software related > to Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Jena was founded 2012-04-18 (9 years ago) > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > > Jena 4.0.0 was released on 2021-04-01. > > This release marks moving from requiring a Java8 platform to requiring a > Java11 platform. After discussion in the dev and users communities, the > feeling was that this was a moment for a major version jump. Because of > this, there was as much removal of deprecated and old code as time > permitted. > > The release was roughly inline with the "release every 3 or 4 months" > ideal that the project has. > > The release date was by-chance! > > This release also contained an updated implementation of "RDF-star" - an > emerging new feature for RDF that is gaining traction. This release > passes all the syntax and evaluation test suites. > > ## Community Health: > > The community, as seen on the user list and via contributors remains > healthy. The thread on whether to update to Java11 was the busiest user > list thread. >
Re: [VOTE] Apache Jena 4.1.0 RC 1
+1 (binding) Verified signatures and checksums Verified that the source and git tag can be built (MacOS, Java 11.0.10) Verified that the OSGi feature can be provisioned (Karaf 4.3.x) Thanks for assembling this release, Aaron On Tue, 1 Jun 2021 at 06:51, Rob Vesse wrote: > +1 (binding) > > Verified signatures and hashes > Verified LICENSE and NOTICE files > Verified that source release can be built > > Rob > > On 01/06/2021, 09:48, "Andy Seaborne" wrote: > > Hi, > > Here is a vote on the release of Apache Jena 4.1.0. > This is the first proposed release candidate. > > The deadline is Friday, 4 June 2021 at 12:00 UTC. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Major items in this release > > * Fixes for IRI handling: > JENA-2097 : UUID IRIs cause RiotException > JENA-2094 : Valid IRI using @ Symbol causes error > > JENA-2109 : jena-permissions update for Jena4. > https://jena.apache.org/documentation/permissions/index.html > > RDF-star implementation - track community work > > JENA-2089 : Datasets+RDFS > Integrated, data-centric RDFS support for RDF Datasets > https://jena.apache.org/documentation/rdfs/ > > Changes to Graph API: > JENA-2909 : Graph.stream(s,p,o) > JENA-2091 : Graph.add(s,p,o) > > Changes for 4.1.0 > > See for JIRA tickets: > https://s.apache.org/jena-4.1.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachejena-1043 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/b46c92106a > > Git Commit Hash: >b46c92106a369879978f95a100d117e79be04f55 > > Git Commit Tag: >jena-4.1.0 > > This vote will be open until at least > > Friday, 4 June 2021 at 12:00 UTC. > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > >Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? > > > > >
Javadocs?
It seems the Javadocs for Jena have all gone missing: https://jena.apache.org/documentation/javadoc/arq/ Are they just in a different location now? (If so, we should change the links from the home page) Thanks, Aaron
Re: [VOTE] Apache Jena 4.2.0 RC1
The signatures and checksums are all good. I tested Jena 4.2.0 with some downstream dependencies that I work on and everything checked out quite well, even those projects that require an older version of Titanium and those that run in a JakartaEE 8 context. I did find that the OSGi deployment failed on the new Titanium dependencies. I have submitted a PR that fixes this: https://github.com/apache/jena/pull/1072 Aaron On Mon, 13 Sept 2021 at 05:50, Bruno P. Kinoshita wrote: > [x] +1 Approve the release > > Building from tag passing on > Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f) > Maven home: /opt/apache-maven-3.8.2 > Java version: 11.0.11, vendor: Ubuntu, runtime: > /usr/lib/jvm/java-11-openjdk-amd64 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-84-generic", arch: "amd64", family: > "unix" > > Started Fuseki, it loaded correctly the datasets I had last used for > development some months ago with no errors. > CheersBruno > > On Monday, 13 September 2021, 12:24:37 am NZST, Andy Seaborne < > a...@apache.org> wrote: > > Hi, > > Here is a vote on the release of Apache Jena 4.2.0. > This is the first proposed release candidate. > > The deadline is Wednesday, 15 September June 2021 at 15:00 UTC. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Major items in this release > > JENA-2112: ShEx engine > https://jena.apache.org/documentation/shex/ > > JENA-1948: JSON-LD 1.1 Reader > JSON-LD 1.1 uses the Titanium system. > https://github.com/filip26/titanium-json-ld > > jsonld-java is still there for JSON-LD 1.0. > In this release, JSON-LD 1.0 is the default for reading JSON-LD. > > This adds new jars into the convenience binaries which > are Eclipse Public License 2.0. > > JENA-2114: SHACL: Provide SPARQL targets > > JENA-2123: Upgrade to Jetty10 > > Contributions: > > Claus Sadler: > JENA-2132 : RDF-star fix > JENA-2154 : Custom SERVICE executors > Experimental: Using SERVICE for extension functionality. > > Erich Bremer: > JENA-2159: schema.org vocabulary > JENA-2155: Add Web Access Control vocabulary > > Jan Martin Keil: > JENA-2142: Extend DatatypeFormatException > > Changes for 4.2.0 > > See for JIRA tickets: > https://s.apache.org/jena-4.2.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejena-1044 > > Proposed dist/ area: > https://dist.apache.org/repos/dist/dev/jena/ > > Keys: > https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): > https://github.com/apache/jena/commit/d346b35f49 @@ > > Git Commit Hash: > d346b35f49e60220f89b3a11c8ed36be778d37a5 > Git Commit Tag: > jena-4.2.0 > > This vote will be open until at least > > Wednesday, 15 September June 2021 at 15:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > > Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive be built? > (NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: [] Apache Jena 4.2.0 RC1
Hi Andy, There are a few things that make OSGi provisioning difficult. Specifically, the jena-osgi artifact (in its current form in 4.2.0-RC-1 and on the main branch) includes the following Import-Package declarations: com.apicatalog.jsonld, com.apicatalog.jsonld.api, com.apicatalog.jsonld.document, com.apicatalog.rdf, com.apicatalog.rdf.spi, jakarta.json;version="[2.0,3)" This requires the titanium and jakarta dependencies to be present. Those dependencies are not present in Jena's features.xml configuration, though a user could add those bundles separately. Unfortunately, the Titanium dependencies are not OSGi bundles, so they cannot be added directly. In Apache Karaf, there is a mechanism by which one can "wrap" a non-OSGi bundle, but this does not work with Titanium. I am not entirely sure why it doesn't work, but I suspect that it is an upstream issue that should be sorted out with the titanium project (I will pursue that separately). There is no particular difficulty installing the jakarta.json bundle, but that is only needed when Titanium is present. By setting those dependencies as optional (as is done in that PR), a user who does not use those features will not need to have those dependencies present. And given that Titanium doesn't appear to work in OSGi, an OSGi user will likely not be using Titanium. I will add, though, that I have more or less given up on working with OSGi -- it presents a lot of challenges that can be hard to sort out (as you can see based on this thread). Plus, in my opinion, many of the advantages of OSGi are relevant only in servers where multiple applications exist in a shared JVM runtime. With runnable jars, docker, kubernetes, etc, I have found deployment models that are much easier to manage than OSGi runtimes. All of which is to say: perhaps the Jena project should consider whether OSGi should be supported in the future. -Aaron On Tue, 14 Sept 2021 at 05:47, Andy Seaborne wrote: > > > On 14/09/2021 01:18, Aaron Coburn wrote: > ... > > I did find that the OSGi deployment failed on the new Titanium > > dependencies. I have submitted a PR that fixes this: > > https://github.com/apache/jena/pull/1072 > > Hi Aaron, > > Not being an OSGi user, I have some simple questions: > > What's the issue here? (what actually goes wrong - the PR says > installing Jena in an OSGi runtime is difficult - does that mean > impossible?) > > Is it with Titanium or the jakarta dependencies? > > If it's Titanium, is there something to ask for upstream? > > Andy >
Re: [] Apache Jena 4.2.0 RC1
Andy, I am happy with that plan for OSGi. As for the 4.2.0 RC1: [x] +1 Approve the release Aaron On Tue, 14 Sept 2021 at 11:20, Andy Seaborne wrote: > Hi Aaron, > > > With runnable jars, docker, kubernetes, etc, I have > > found deployment models that are much easier to manage than OSGi > > runtimes. All of which is to say: perhaps the Jena project should > > consider whether OSGi should be supported in the future. > > Agreed. I can't recall when it was last mentioned on users@ and multiple > applications in the same JVM are not in fashion. I'd guess these systems > are unlikely to upgrade very frequently either. > > We've said previously that OSGi was not one the main parts of Jena. > > How about: > > 1/ Remove the OSGi convenience binaries, that is - apache-jena-osgi > jena-osgi and jena-osgi-features so that don't go to maven repo1. > > > https://repository.apache.org/content/repositories/orgapachejena-1044/org/apache/jena/ > > TIL: The Nexus repo let's us delete subtrees. > > 2/ Put in the announcement to users@ that there is no OSGi binaries in > this release due to late-emerging problems. > > 3/ Ask for any users to let us knowif they use the OSGi packaging. > > > In other words, leave the release source artifact (THE release) alone. > > > If necessary, someone can build from that, with fixes, and still be > using an official Jena release. > > Absent anyone offering to help, we retire OSGi. > > If there is sufficient demand, do 4.2.1 with fixed OSGi. > > If you're happy to vote for the release with that plan - and so is > Bruno, who has voted - I will then test the proposed, revised maven tree > from an independent project. > > This delays doing another build prior to 4.3.0 until we know whether it > is needed - whether OSGi (and know it's been confirmed as working) or > some other thing that emerges. > > Andy > > On 14/09/2021 14:38, Aaron Coburn wrote: > > Hi Andy, > > There are a few things that make OSGi provisioning difficult. > Specifically, > > the jena-osgi artifact (in its current form in 4.2.0-RC-1 and on the main > > branch) includes the following Import-Package declarations: > > > > com.apicatalog.jsonld, > > com.apicatalog.jsonld.api, > > com.apicatalog.jsonld.document, > > com.apicatalog.rdf, > > com.apicatalog.rdf.spi, > > jakarta.json;version="[2.0,3)" > > > > This requires the titanium and jakarta dependencies to be present. Those > > dependencies are not present in Jena's features.xml configuration, > though a > > user could add those bundles separately. Unfortunately, the Titanium > > dependencies are not OSGi bundles, so they cannot be added directly. In > > Apache Karaf, there is a mechanism by which one can "wrap" a non-OSGi > > bundle, but this does not work with Titanium. I am not entirely sure why > it > > doesn't work, but I suspect that it is an upstream issue that should be > > sorted out with the titanium project (I will pursue that separately). > There > > is no particular difficulty installing the jakarta.json bundle, but that > is > > only needed when Titanium is present. By setting those dependencies as > > optional (as is done in that PR), a user who does not use those features > > will not need to have those dependencies present. And given that Titanium > > doesn't appear to work in OSGi, an OSGi user will likely not be using > > Titanium. > > > > I will add, though, that I have more or less given up on working with > OSGi > > -- it presents a lot of challenges that can be hard to sort out (as you > can > > see based on this thread). Plus, in my opinion, many of the advantages of > > OSGi are relevant only in servers where multiple applications exist in a > > shared JVM runtime. With runnable jars, docker, kubernetes, etc, I have > > found deployment models that are much easier to manage than OSGi > runtimes. > > All of which is to say: perhaps the Jena project should consider whether > > OSGi should be supported in the future. > > > > -Aaron > > > > > > > > On Tue, 14 Sept 2021 at 05:47, Andy Seaborne wrote: > > > >> > >> > >> On 14/09/2021 01:18, Aaron Coburn wrote: > >> ... > >>> I did find that the OSGi deployment failed on the new Titanium > >>> dependencies. I have submitted a PR that fixes this: > >>> https://github.com/apache/jena/pull/1072 > >> > >> Hi Aaron, > >> > >> Not being an OSGi user, I have some simple questions: > >> > >> What's the issue here? (what actually goes wrong - the PR says > >> installing Jena in an OSGi runtime is difficult - does that mean > >> impossible?) > >> > >> Is it with Titanium or the jakarta dependencies? > >> > >> If it's Titanium, is there something to ask for upstream? > >> > >> Andy > >> > > >
Re: Jena & OSGi artifacts
That particular SO issue comes from the use of Jena in the Islandora project. I reached out to some developers I know in that community to ask about their plans for using Jena in an OSGi context. Apparently, they are moving away from OSGi, likely in the direction of runnable jars. In fact, the reaction I got from them when I described this situation wasn't "please fix this in Jena" but rather "that's a good reason to prioritize moving away from OSGi". -Aaron On Sat, 18 Sept 2021 at 14:13, Andy Seaborne wrote: > In the 4.2.0 release, the OSGi artifacts were pulled from the > convenience binaries because they didn't work properly. > > Only Aaron's diligent testing caught this. > > The new problem is with the new dependency - Titanium JSON-LD not being > OSGi compatible. There is a quick fix in the code making Titanium > optional for the OSGi bundle but that seems rather unsatisfactory and > blocks us switching to Titanium for JSON-LD reading by default. > > Testing of OSGi within the build has skipped because it does not work > The tests setup fails for a single build from empty and the release, and > release checking, do exactly that. JENA-913. > > To add to the OSGi situation, this appeared 2021-09-16 (the first > mention I know of of Jena+OSGi for a while.) > > https://stackoverflow.com/questions/69180521/karaf-unable-to-install-jena > > So some system is using Jena with OSGi - it is not clear whether it is > using our Jena OSGi binary or not. > > What to do about it? > > We don't have OSGi skills any more - there are many ways to deploy these > days and it seems OSGi isn't now important to anyone here. > > Andy >
Re: [DRAFT] Apache Jena report - 2021-10
+1 Thank you, indeed On Thu, 30 Sept 2021 at 17:44, Bruno P. Kinoshita wrote: > +1 > Thanks! > > On Friday, 1 October 2021, 10:34:51 am NZDT, Andy Seaborne < > a...@apache.org> wrote: > > ## Description: > The mission of Jena is the creation and maintenance of software related > to Java framework for building Semantic Web applications > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Jena was founded 2012-04-18 (9 years ago). > There are currently 18 committers and 14 PMC members in this project. > The Committer-to-PMC ratio is 9:7. > > Community changes, past quarter: > - No new PMC members. Last addition was Aaron Coburn on 2019-01-22. > - No new committers. Last addition was Greg Albiston on 2019-07-08. > > ## Project Activity: > Jena version 4.2.0 was released 2021-09-12. It fixed CVE-2021-39239, > which was discovered by the team, and affects all version 4.1.0 and > earlier. > > The release was not just about a CVE fix. The release included a new > component, a data validation engine for the ShEx language to go > alongside the SHACL engine; and also support for reading JSON-LD 1.1 > using an external 3rd party library. JSON-LD 1.1 is used by some IOT > device and service descriptions. > > During the release checking, a problem was discovered in the OSGi bundle > related to the new dependencies for JSON-LD 1.1 handling. The project > dropped the OSGi convenience binaries, and a discussion has started > about retiring them. The development community no longer has the skills, > nor interest, necessary to maintain their production. Contact with known > downstream open source projects, and a message to users@ has not > produced any concern. > > Jena has a process for retiring modules - delete in git, record the last > git commit with the code in case some interest emerges and will maintain > the module. > > ## Community Health: > Activity seems normal. Some of the figures are slightly skewed because > one PR had 48 commits which is unusual for Jena. > > The dev@ list is also the destination of JIRA email and is otherwise > quite quiet. The speed of evolution of the project is down to developer > time. > > The users@ is active and the main support channel. >
Re: Towards Jena 4.3.0
+1 On Wed, Nov 17, 2021, 20:24 wrote: > +1 indeed. > > Adam > > On Wed, Nov 17, 2021, 4:33 PM Bruno P. Kinoshita > wrote: > > > >Does that fit with PMC members? > > +1 > > Thanks Andy! > > Bruno > > > > On Wednesday, 17 November 2021, 11:09:35 pm NZDT, Andy Seaborne < > > a...@apache.org> wrote: > > > > We're a little way from the clock tick - 3 months would be 16/Dec. > > > > From my point of view, it would be nice to release early to mid > > December rather than the run up to Christmas. > > > > Does that fit with PMC members? > > > > Andy > > > > Resolved tickets for 4.3.0: > > https://s.apache.org/jena-4.3.0-jira > > > > Jenkins: > > https://ci-builds.apache.org/job/Jena/ > > > > and the additional CI builds on Windows and MacOS pass. > > https://github.com/apache/jena/actions > > > > Contributions: > > > > Jan Martin Keil > > JENA-2169: Blank node graph names in Dataset interface > > > > Erich Bremer > > Update EnhGraph.java > > > > Stefan Obermeier > > JENA-2195: Include jena-examples in build > > > > jena-site: > > Michael Wechner > > @den1s0v > > Robin Vobruba > > > > Main Items: > > > > java.net.http > > > > HTTP usage provided by the JDK java.net.http package, with > > challenge-based authentication provided on top by Jena. > > > > Rework SPARQL client APIs using HTTP code (query, update GSP). > > > > SPARQL APIs > > > > * Execution objects (QueryExecution, UpdateExecution, RDFConnection) > > have a companion builders for detailed configuration. Previous factory > > classes remain but builders are preferred. > > > > This is especially important for HTTP as there many configuration > > options that may be needed (including template queries). > > > > https://jena.apache.org/documentation/sparql-apis/#changes > > > > Epic: JENA-2125 > > > > Internal reorg: > > > > > https://lists.apache.org/thread.html/r02f8938a5fea60f6dd1781dabcb81862abebd19052b076fad57340db%40%3Cusers.jena.apache.org%3E > > > > If apps use methods that have Apache HttpClient arguments (HttpClient, > > HttpContext), they will be affected. > > > > xloader > > > > TDB1 and TDB2 loader for billion+ triples on a modest machine. > > > > JENA-2175 > > xloader > > tdbloader2 renamed. tdb1.xloader > > tdb2.xloader > > > > Retire OSGi artifacts > > JENA-2165 > > > > jena-examples > > Consolidate ARQ/TDB/ShEx/SHACL and RDFConnection examples > > >
Re: [VOTE] Apache 4.3.0 RC 1
[X] +1 Approve the release Verified signatures Verified checksums Built on Java 11 and 17 from git tag (OS X, maven 3.8.2) Built on Java 11 and 17 from source archive (OS X, maven 3.8.2) LICENSE and NOTICE files are present Thanks for managing this release! -Aaron On Mon, 6 Dec 2021 at 03:43, Andy Seaborne wrote: > Hi, > > Here is a vote on the release of Apache Jena 4.3.0. > This is the first proposed release candidate. > > The deadline is Thursday, 9 December 2021 at 09:00 UTC. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Contributors > > Stefan Obermeier > - Add jena-examples to modules in parent pom > > Erich Bremer > - Update EnhGraph.java > > Florian Kleedorfer > - Fix copy/paste error in validation report message > > Jan-Martin Keil > - Dataset: enable named Models with blank node name > > jena-site: >Michael Wechner >michi AT wyona.com >@den1s0v >Robin Vobruba > > Major items in this release > > There is a change to use JDK java.net.http > package for HTTP. This affects authentication. > > There is also a lot of code cleanup around SPARQL operations. > Deprecation indicate methods that will be removed in the future. > > Fuseki users are not affected by these changes. > > JENA-2175 >(tdbloader2 renamed). tdb1.xloader & tdb2.xloader >https://jena.staged.apache.org/documentation/tdb/tdb-xloader.html > > Loader for large data on modest hardware. 1B triples and beyond. > > JENA-2171: str(bnode) now returns string, not an error. > > JENA-2173: Async parser > > https://github.com/apache/jena/blob/main/jena-examples/src/main/java/arq/examples/riot/ExRIOT9_AsyncParser.java > > JENA-2187 : JSON-LD prefixes fix > > JENA-2182: Fuseki modules (experimental) > > JENA-2179 -> JENA-2186: Handling U+FFFD >Print as \uFFFD, warn if seen raw. > > Epic: JENA-2125 > Internal reorg: > > https://lists.apache.org/thread.html/r02f8938a5fea60f6dd1781dabcb81862abebd19052b076fad57340db%40%3Cusers.jena.apache.org%3E > > JENA-2165 > Retire OSGi > > JENA-2176: Protobuf encoding > > TDB2 node cache default -> 750k->1e6 > > JENA-2195: jena-examples >examples consolidated > > Migration to java.net.http: > > * HTTP usage provided by the JDK java.net.http package, with > challenge-based authentication provided on top by Jena. > > * Execution objects (QueryExecution, UpdateExecution, RDFConnection) > have a companion builders for detailed configuration. Previous factory > classes remain but builders are preferred. > > This is especially important for HTTP as there many configuration > options that may be needed (including template queries). > > * Timeouts - remote only supports the overall query execution. > (connection timeout on HttpClient but due to connection caching and now > HTTP/2 it is unclear how meaningful that is per request) > > * HTTP/2 support (comes from using java.net.http package) > > See notes on changes: > > https://jena.apache.org/documentation/sparql-apis/#changes > > Changes for 4.3.0 > > See for JIRA tickets: > https://s.apache.org/jena-4.3.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachejena-1045 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/bf0fd7e9f0 > Git Commit Hash: >bf0fd7e9f034ffdbf8666023131efd2e77b9b857 > Git Commit Tag: >jena-4.3.0 > > This vote will be open until at least > > Thursday, 9 December 2021 at 09:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > >Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: [VOTE] Apache Jena 4.3.1 RC 1
[X] +1 Approve the release (binding) Verified signatures Verified checksums Built from source dist with JDK 11 & 17 on Mac Built from SCM tag with JDK 11 & 17 on linux LICENSE/NOTICE files are present and look good Thanks for the quick turn-around on this. Aaron On Fri, 10 Dec 2021 at 11:40, Andy Seaborne wrote: > Hi, > > Here is a vote on the release of Apache Jena 4.3.1. > This is the first proposed release candidate. > > The primary purpose of this release is to update log4j2: > https://nvd.nist.gov/vuln/detail/CVE-2021-44228 > > The deadline is Monday, 13 December 2021 at 17:00 UTC. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Items in this release > > JENA-2211: Upgrade to Log4j2 2.15.0 > > JENA-2209, JENA-2210: xloader improvements > > JENA-2207: Fix for SERVICE > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachejena-1046 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/7f47eaaf7c > Git Commit Hash: >7f47eaaf7cc0029291ce64790da987ec2d29fdf5 > Git Commit Tag: >jena-4.3.1 > > This vote will be open until at least > > Monday, 13 December 2021 at 17:00 UTC. > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > >Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: [VOTE] Apache Jena 4.3.2 RC 1
+1 (binding) checksums are good signatures are good LICENSE/NOTICE files are present and look good Source distribution is buildable (MacOS, jdk11) git tag is buildable (MacOS, jdk11) Aaron On Fri, 17 Dec 2021 at 15:17, Andy Seaborne wrote: > +1 (binding) > > Andy > > On 17/12/2021 20:10, Andy Seaborne wrote: > > Hi, > > > > ** This is a fast-track release ** > > > > Here is a vote on the release of Apache Jena 4.3.2. > > This is the first proposed release candidate. > > > > The primary purpose of this release is to update log4j2 2.16.0 to > > address CVE-2021-45046 > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046 > > https://logging.apache.org/log4j/2.x/security.html > > > > where the severity has been raised to Critical. > > > > Apache Jena 4.3.1 addressed CVE-44228. > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 > > > > The deadline is > > > > Sunday, 19 December 2021 at 06:00 UTC. > > > > ** Short deadline ** > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > Items in this release > > > > JENA-2214: Update log4j2 to 2.16.0 > > > > JENA-2216: Depend on jena-cmds as does fuseki-main > > JENA-2215: Make log4j impl scope-runtime for war-plugin > > JENA-2215: Be clear that log4j is not optional to shading. > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1047 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/7692c4cf4 > > Git Commit Hash: > >7692c4cf4a0cad18eb690a33653c8a256e8f424f > > Git Commit Tag: > >jena-4.3.2 > > > > This vote will be open until at least > > > > Sunday, 19 December 2021 at 06:00 UTC. > > > > ** Short deadline ** > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
Re: Towards Jena 4.5.0
On Thu, Apr 28, 2022, 5:51 AM Andy Seaborne wrote: > There are several PRs in progress, in draft or in discussion, including > a new one for a replacement of the in-memory graph which is more space > efficient. > > There are also significant things ready for release; better JSON SPARQL > results, and switch to JSON-LD 1.1 > > That makes the choice of release 4.5.0 on schedule, keep progressing the > up-and-coming features and maybe release 4.6.0 earlier than the normal > clock tick cycle, or wait and do one release. > > If the PMC has the bandwidth, I'm happy to release ASAP and then do then > next release quite soon after. > Either way works for me. I have time to review. Aaron > It seems to me to be better to switch the mem graph replacement at the > start of a cycle. > > Andy > > On 24/04/2022 11:12, Andy Seaborne wrote: > > On 05/04/2022 08:56, Andy Seaborne wrote: > >> == Considerations > >> > >> Whether to switch to reading JSON-LD 1.1 by default. > > > > Pending: > > > > * SHACL ValidationListener > >https://github.com/apache/jena/pull/1256 > > Currently, this is draft. > > > (rules) > > * fix for custom builtins not being used when parsing rules > >https://github.com/apache/jena/pull/1268 > > Looks OK. > > > > > * JSON-LD 1.1 > >Currently asking on users@ > > Codebase is now set for JSON-LD 1.1, both reading and writing. >
Re: [VOTE] Apache Jena 4.5.0 RC1
[x] +1 Approve the release (binding) Verified signatures Verified checksums Built jena from source archive using Java 11 and Maven 3.8.1 All artifacts contain LICENSE and NOTICE files Thanks, Aaron On Mon, May 2, 2022 at 1:53 AM Bruno Kinoshita wrote: > [x] +1 Approve the release > > Thanks > Bruno > > On Mon, 2 May 2022 at 03:18, Andy Seaborne wrote: > > > Hi, > > > > Here is a vote on the release of Apache Jena 4.5.0. > > This is the first release candidate. > > > > The deadline is > > > > Wednesday, 4th May 2022 at 18:00 UTC > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > Items in this release > > > > * New, faster, streaming, more robust JSON result set reader. > > > > * Switch to JSON-LD 1.1 as the JSON-LD default. > > > > To get valid javadoc, the build was done with Java17 cross-compiling to > > 11. A dry-run with java11 was done to check that no > > Java17 library calls had crept in. > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1052 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL):91c399148f > >https://github.com/apache/jena/commit/91c399148f > > > > Git Commit Hash: > >91c399148f4f94c19517a88eb8c85db83fdb1342 > > > > Git Commit Tag: > >jena-4.5.0 > > > > This vote will be open until at least > > > > Wednesday, 4th May 2022 at 18:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above. > > > > Thanks, > > > > Andy > > > > Checking: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > + can the source archive be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? > > >
Re: [VOTE] Apache Jena 4.6.0 RC1
[x] +1 Approve the release (binding) Built from source distribution and from git tag Signatures are all good Checksums are all good LICENSE files are present and look good NOTICE files are present and look good Thank you, Andy, once again for all that you're doing. -Aaron On Wed, Aug 24, 2022 at 2:33 PM Andy Seaborne wrote: > Ping - could we get another PMC +1 vote please. > > Andy > > On 20/08/2022 11:48, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on the release of Apache Jena 4.6.0. > > This is the first release candidate. > > > > The deadline is > > > > Wednesday, 24th August 2022 at 12:00 UTC > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... >
Re: [VOTE] Apache Jena 4.7.0 RC1
[X] +1 (binding) Checked signatures and checksums Built from the source distribution Built from the git tag license/notice files look good Aaron On Tue, Dec 20, 2022 at 11:39 AM Andy Seaborne wrote: > Hi, > > Here is a vote on the release of Apache Jena 4.7.0. > This is the first release candidate. > > The deadline is > > Friday, 23rd December 2022 at 18:00 UTC > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Items in this release > > https://s.apache.org/jena-4.7.0-issues > > Major: > > * Lucene upgrade 8.11.1 to 9.4.1 - @OyvindLGjesdal > There are changes to the stopword setting in the default > configuration of Lucene's StandardAnalyzer >Issue: https://github.com/apache/jena/issues/1581 >PR: https://github.com/apache/jena/pull/1582 > > * LATERAL joins > This is an experimental feature. >Issue: https://github.com/apache/jena/issues/1615 >Documentation: >https://jena.apache.org/documentation/query/lateral-join.html > > * RDF Patch > https://lists.apache.org/thread/8oc1gn2qnzx4ddwovx8h545jm270gpyx >Issue: https://github.com/apache/jena/issues/1618 >PR: https://github.com/apache/jena/pull/1619 >Documentation: https://github.com/apache/jena-site/pull/131 > > * Path improvements - @SimonBin et al >https://github.com/apache/jena/pull/1616 >https://github.com/apache/jena/pull/1638 >Plan: https://github.com/apache/jena/issues/1629 > > * Source code folder reorganisation >Rename jena-tdb directory as jena-tdb1 >Move jena-tdb2 directory to the top level directory >Issue: https://github.com/apache/jena/issues/1539 >Issue: https://github.com/apache/jena/issues/1540 > > Contributors: >OyvindL Gjesdal >Simon Bin >Alexandre Ardhuin >Claus Stadler >Brian Vvosburgh >Eric Prud'hommeaux > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachejena-1055 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/3a62b5a5f1 > > > Git Commit Hash: >3a62b5a5f162ef01fd46164fa11ffb5323169a61 > > Git Commit Tag: >jena-4.7.0 > > This vote will be open until at least > > Friday, 23rd December 2022 at 18:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above. > > Thanks, > > Andy > > Checking: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > + can the source archive be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: [VOTE] Apache Jena 4.8.0 RC2
+1 (binding)
The checksums and signatures are all good
I was able to build from the git tag and the source distribution
LICENSE and NOTICE files look good
I have tested the release successfully in downstream projects
Thank you, Andy!
On Thu, Apr 20, 2023 at 9:57 PM Bruno Kinoshita wrote:
> +1 and I confirm the tests are now all passing on my environment
>
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-70-generic", arch: "amd64", family:
> "unix"
>
> Thank you Andy!
>
>
> On Thu, 20 Apr 2023 at 11:27, Andy Seaborne wrote:
>
> > Hi,
> >
> > Here is a vote on the release of Apache Jena 4.8.0.
> > This is the second release candidate.
> >
> > The deadline is
> >
> > Sunday, 23rd April 2023 at 12:00 UTC
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] 0 Don't care
> > [ ] -1 Don't release, because ...
> >
> > Items in this release
> >
> > == RC 2
> >
> > a/ Fix the initialization issue found in RC1
> > https://github.com/apache/jena/pull/1847
> >
> > b/ GH-1749: Replacing webpack chunks by Vite rollup
> >
> > c/ fix and test for JENA-2352
> >
> > == RC 1
> >
> > https://s.apache.org/jena-4.8.0-issues
> >
> > * The RDF/XML parser has been converted to use the
> >Jena IRI abstraction IRIx.
> >https://github.com/apache/jena/issues/1773
> >
> > This is the first part of a move to convert the RDF/XML parser to be
> > consistent with the rest of Jena parsing
> >
> > 1. unified IRI treatment of error handling and reporting throughout Jena
> > 2. improve maintainability
> > 3. allow for alternative providers of IRI functionality
> >
> > * Add CHANGES.txt
> > https://github.com/apache/jena/blob/main/CHANGES.txt
> >It has been backfilled with announcement message from 4.0.0 onwards.
> >It will be updated after the release - it has a link to [ANN]
> >
> > * Search facility on the Jena website
> >
> > @lucasvr (Lucas C. Villa Real) provided an analysis and improvement to
> > bulk loading operations.
> >https://github.com/apache/jena/issues/1803
> >https://github.com/apache/jena/pull/1819
> >
> > @wjl110 - Shiro upgrade PR#1728
> >https://github.com/apache/jena/pull/1728
> >
> > Lucene upgrade from 9.4.2 to 9.5.0
> >https://github.com/apache/jena/pull/1740
> >https://lists.apache.org/thread/696xgpyg2441kzdowmp1b40tshctw25c
> >
> > @dplagge (Daniel Plagge) - Delta graph fix
> > https://github.com/apache/jena/issue/1751
> >
> > SimonBin: Fix for sharing link in Fuseki and YASGE
> >https://github.com/apache/jena/issues/1745
> >
> > Improved performance of "GRAPH ?g {}" (all graph names)
> > Prefix scan -- GRAPH ?G
> >https://github.com/apache/jena/issues/1639
> >https://github.com/apache/jena/pull/1655
> >
> > @nichtich (Jakob Voß) jena-site improvements:
> >https://github.com/apache/jena-site/pull/151
> >
> > @sverholen JENA-2350 Pass JsonLdOptions to titanium for json-ld 1.1
> >
> > Release Vote
> >
> > Everyone, not just committers, is invited to test and vote.
> > Please download and test the proposed release.
> >
> > Staging repository:
> >https://repository.apache.org/content/repositories/orgapachejena-1058
> >
> > Proposed dist/ area:
> >https://dist.apache.org/repos/dist/dev/jena/
> >
> > Keys:
> >https://svn.apache.org/repos/asf/jena/dist/KEYS
> >
> > Git commit (browser URL):
> >https://github.com/apache/jena/commit/198e6950c7
> >
> > Git Commit Hash:
> >198e6950c7652ffe68c9171bc5ed92c69210c60a
> >
> > Git Commit Tag:
> >jena-4.8.0
> >
> > This vote will be open until at least
> >
> >Sunday, 23rd April 2023 at 12:00 UTC
> >
> > If you expect to check the release but the time limit does not work
> > for you, please email within the schedule above.
> >
> > Thanks,
> > Andy
> >
> > Checking:
> >
> > + are the GPG signatures fine?
> > + are the checksums correct?
> > + is there a source archive?
> > + can the source archive be built?
> >(NB This requires a "mvn install" first time)
> > + is there a correct LICENSE and NOTICE file in each artifact
> >(both source and binary artifacts)?
> > + does the NOTICE file contain all necessary attributions?
> > + have any licenses of dependencies changed due to upgrades?
> > if so have LICENSE and NOTICE been upgraded appropriately?
> > + does the tag/commit in the SCM contain reproducible sources?
> >
>
Re: [VOTE] Release vote : Apache Jena 3.2.0
+1 (non-binding) Works on OS X > On Feb 2, 2017, at 7:02 AM, Andy Seaborne wrote: > > +1 (binding) > >>> Please vote to approve this release: >>> >>>[ ] +1 Approve the release >>>[ ] 0 Don't care >>>[ ] -1 Don't release, because ... >>> >>> This vote will be open to the end of >>> >>> Monday, 6 February, 23:59 UTC >>> >>> Thanks to everyone who can help test and give feedback of every kind! >>> >>> ajs6f (A. Soroka) >>> >>> >>> Checking needed: >>> >>> • Does everything work on MS Windows? >>> • Does everything work on OS X? > > Works on Linux. > >>> • Is the GPG signature okay? > > Yes > > And the integrity md5 and sha1 checksums. > >>> • Is there a source archive? > > Yes > >>> • Can the source archive really be built? > > Yes > >>> • Is there a correct LICENSE and NOTICE file in each artifact (both >>> source and binary artifacts)? > > I pick some at random and they look good. > > I checked jena-rdfconnection as it is new. > >>> • Does the NOTICE file contain all necessary attributions? > > Yes > >>> • Does the tag in the SCM contain reproducible sources? > > Yes
CMS diff: Reification HowTo
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fnotes%2Freification.mdtext Aaron Coburn Index: trunk/content/documentation/notes/reification.mdtext === --- trunk/content/documentation/notes/reification.mdtext(revision 1655891) +++ trunk/content/documentation/notes/reification.mdtext(working copy) @@ -2,7 +2,7 @@ ## Introduction -This document describes the Jena APi support for reification. +This document describes the Jena API support for reification. it. As always, consult the Javadoc for interface details. @@ -127,8 +127,8 @@ ## Reification styles -Prior to version 2.10.0 of Jena, there were 3 styles of reificiation, +Prior to version 2.10.0 of Jena, there were 3 styles of reification, "standard", "minimal" and "convenient". As of 2.10.0 and later, only -what was prviosuly the "standard" style is supported. +what was previously the "standard" style is supported. The old documentation is [still available](reification_previous.html).
Re: Release Jena 3.5.0?
Would it make sense to add an Automatic-Module-Name header to the manifest files so that Jena is easier to use in a JDK9 context? I could even volunteer to do this. Aaron > On Oct 17, 2017, at 9:56 AM, aj...@apache.org wrote: > > Claude-- > > I see some updates available for the contract test machinery: > > org.xenei:contract-test-maven-plugin .. 0.1.5 -> 0.1.7 > org.xenei:junit-contracts . 0.1.5 -> 0.1.7 > > Worth doing before a release? > > > ajs6f > > Andy Seaborne wrote on 10/16/17 6:32 PM: >> The tick is approaching. >> Are we ready to go? JIRA to be marked resolved? >> >> If so, I'll sort out a release soon. >> >> Andy >> >> Here's a list of changes of note that I gathered: >> >> Release changes >> >> Introducing TDB2: >> http://jena.staging.apache.org/documentation/tdb2/ >> >> *TDB2 is not compatible with TDB1* >> >> Compared to TDB1: >> * No size limits on transactions : bulk uploads into a live Fuseki >> can e 100's of millions of triples. >> * Models and Graphs can be passed across transactions >> * No queue of delayed updates, no transaction backlog problems. >> * "Writer pays" - readers don't >> All work for update is done on the writer thread. >> * Datatypes of numerics preserved; xsd:doubles supported. >> >> TDB2 is subject to change. >> >> We solicit any and all feedback (good and bad!) about TDB2 to help >> advance it to deployment-ready. >> >> JENA-1390 : Add StmtIterator.toModel : >> >> JENA-1392 : Add dynamic dataset support to SDB. >> >> JENA-1395 : "--output RDF/XML" now prints using the basic block-oriented >> writer, which uses less memory. Use "--formatted" (same as "--pretty") >> for pretty printed RDF/XML. >> >> JENA-1398 : >> Upgrade FOAF to add new spelling and deprecation of old for archaic FOAF >> properties >> >> == Dependency changes: >> >> No license changes. >> >> Upgrade jsonld-java to 0.11 >> jackson to 2.9.0 >> commons-fileuploader to 1.3.2->1.3.3 >> commons-io 2.5 in jena-base >>(was pulled in anyway by jsonld-java) >> signature.asc Description: Message signed with OpenPGP
Re: Welcome Aaron!
Thanks so much, Andy! I look forward to continuing to be involved in the Jena code and community. -Aaron > On Jun 18, 2018, at 10:50 AM, Andy Seaborne wrote: > > We're pleased to announce that Aaron Coburn (acoburn@) has become > a committer for Apache Jena. > > Welcome Aaron! > > Andy > on behalf of the Apache Jena PMC
Re: Commit workflow
Thanks Andy, this is very helpful. Best, Aaron > On Jun 20, 2018, at 6:02 AM, Andy Seaborne wrote: > > Aaron, Chris, all, > > One thing to mention - with the master repo on Apache hardware and PRs on the > mirror (which we don't have write access to) there is a workflow for merging > into the Apache github repo: > > https://cwiki.apache.org/confluence/display/JENA/Commit+Workflow+for+Github-ASF > >Andy > > (gitbox?)
Re: [VOTE] Apache Jena 3.10.0 RC1
+1 (non-binding) Builds on OS X with both Java 8 and Java 11 using Maven 3.5.4. I verified that the OSGi module works in Karaf 4.2 The Automatic-Module-Name metadata looks good across all the artifacts The Jena-based Commons-RDF module works with this RC Aaron > On Dec 31, 2018, at 11:10 AM, ajs6f wrote: > > See question about checksums below. > >> + does everything work on OS X? > > Seems to. > >> + are the GPG signatures fine? > > Yes. > >> + are the checksums correct? > > Hm, yes for the binaries, but for sources, my edition of shasum doesn't > recognize the file: > > ➜ source /usr/bin/shasum5.18 -a 512 -c jena-3.10.0-source-release.zip.sha512 > shasum: jena-3.10.0-source-release.zip.sha512: no properly formatted SHA1 > checksum lines found > > because it only contains the checksum itself: > > d0b5e47616c847d76e77f214b0c346ece34950eb0a8e0e74bfe41888cc85d63aef8149543bc84711c3c2e2442cb5151dd5a66013ccc0805c5b3ec245d6463204 > > and not also the filename to which it applies, e.g. : > > 7dafe7aa28cb85a6da9f6f2b109372ec0d097d4f07d8cb5882dde814b55cdb60512ab9bc09c2593118aaf3fbbc1f65f1d3b921faca7bddefd3f6bf9d7f332998 > apache-jena-3.10.0.tar.gz > > Is that a blocker for release? I'm not sure how precise the rules are about > the format of checksums. Do we just need to include them or to include them > in a certain format? > > >> + is there a source archive? > > Yes, built fine for me using Maven 3.5.3: > > Maven home: /usr/local/Cellar/maven/3.5.3/libexec > Java version: 1.8.0_65, vendor: Oracle Corporation > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" > >> + can the source archive really be built? >>(NB This requires a "mvn install" first time) > > Yes. > >> + is there a correct LICENSE and NOTICE file in each artifact >>(both source and binary artifacts)? > > Yes. > >> + does the NOTICE file contain all necessary attributions? > > I don't really know how to certify the NOTICE. It's correct to the best of my > knowledge? > >> + does the tag/commit in the SCM contain reproducible sources? > > Yes. > > ajs6f > >> On Dec 30, 2018, at 12:31 PM, Andy Seaborne wrote: >> >> Hi, >> >> Here is a vote on a release of Jena 3.10.0. >> This is the first proposed release candidate. >> >> The deadline for the vote is Wednesday, 2 January 2019, at 21:00 UTC >> >> Release changes: >> >> 44 JIRA: >> >> https://s.apache.org/jena-3.10.0-jira >> >> == Retirements >> >> Old modules retired and not in this release: >> >> jena-fuseki1 >> jena-csv >> >> See >> https://lists.apache.org/thread.html/edd5876b070f24091e19b5c1dd274ef46c74a0f920d419a29a59f66b@%3Cusers.jena.apache.org%3E >> >> == Changes of note: >> >> The project intends to replace jena-spatial in a future release with Greg's >> GeoSPARQL: >> https://github.com/galbiston/geosparql-jena >> >> JENA-1621 : Lucene upgrade to 7.4 >> May need to reload Lucene indexes. >> >> (e.g. the Lucene index was create originally with Lucene v5.x (prior Jena >> 3.3.0). See Lucene upgrade tool. >> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html >> >> JENA-1623 : Fuseki security - user authentication and access control. >> JENA-1627 : HTTPs support >> >> http://jena.staging.apache.org/documentation/fuseki2/data-access-control >> >> == Updates >> >> Only plugins. JENA-1624 >> >> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588) >> compiler : 3.7.0 -> 3.8.0 >> shade: 3.1.0 -> 3.2.0 >> >> Release Vote >> >> Everyone, not just committers, is invited to test and vote. >> Please download and test the proposed release. >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachejena-1028 >> >> Proposed dist/ area: >> https://dist.apache.org/repos/dist/dev/jena/ >> >> Keys: >> https://svn.apache.org/repos/asf/jena/dist/KEYS >> >> Git commit (browser URL): >> https://github.com/apache/jena/commit/ab482e34 >> >> Git Commit Hash: >>ab482e34584350af717db1a8d698aa3949e51871 >> >> Git Commit Tag: >>jena-3.10.0 >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] 0 Don't care >> [ ] -1 Don't release, because ... >> >> This vote will be open to at least >> >> Wednesday, 2 January 2019, at 20:00 UTC >> >> If you expect to check the release but the time limit does not work >> for you, please email within the schedule above with an expected time >> and we can extend the vote period. >> >> Thanks, >> >>Andy >> >> Checking needed: >> >> + does everything work on Linux? >> + does everything work on MS Windows? >> + does everything work on OS X? >> + are the GPG signatures fine? >> + are the checksums correct? >> + is there a source archive? >> >> + can the source archive really be built? >>(NB This requires a "mvn install" first time) >> + is there a correct LICENSE and NOTICE file in each artifact >>(both s
Re: Sonar?
It is possible to exclude specific modules from Sonar's analysis (I do this with some of my own projects). The documentation for this is here: https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven#AnalyzingwithSonarQubeScannerforMaven-ExcludingamodulefromSonarQubeanalysis Basically, you define this property in the module you want to skip: true Aaron On Tue, Apr 16, 2019 at 8:49 AM Rob Vesse wrote: > Yep > > A lot of the bigger projects (often those with commercial backers) that > have a much higher rate of change are often very nit-picky about things > like code style e.g. Apache Spark. I've on occasion spent weeks going back > and forth on style nits in the past with PRs for Spark! > > I can see where those projects are coming from, if you have a high rate of > PRs and changes a consistent code style reduces the unnecessary noise in > code reviews but it tends to be very unwelcoming to new contributors. > > So yes I'd never want us to implement that for Jena > > Rob > > On 16/04/2019, 13:10, "ajs6f" wrote: > > Whoa, wait what?! Are there Apache projects that do that? (Require > some certain score on this kind of analysis for a contribution?) I > sincerely hope not, and I'd be the first -1 here at Jena against any such > suggestion. That would be literally thoughtless. > > > > >
Re: Towards Jena 3.11.0
Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. (But either way is fine with me) Aaron On Wed, Apr 17, 2019 at 6:47 AM wrote: > +1 to releasing 3.11.0 as described and not loading it up any further. > > ajs6f > > On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > > > We seem to be trying to do too much in one release. As ever, people get > > busy. > > > > https://s.apache.org/jena-3.11.0-jira > >36 JIRA > > > > including fixes like JENA-1657 "Close response stream of http > connections". > > > > While not a major problem at the moment, it can start to cause blockage > > for other work. > > > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > > with a 3.12 ... hoping to get it all done during May. > > > > Or we could just accept a delay to 3.11.0. > > > > It is the usual tension between perfect and timely with volunteer time! > > > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > > for me. > > > > Thoughts? > > > > Andy > > > > On 03/04/2019 21:16, Andy Seaborne wrote: > > > We have three major streams outstanding. > > > Have I missed anything? > > > > > > 1/ GeoSPARQL > > > 2/ Prometheus metrics > > > 3/ SurroundQueryParser > > > > > > == GeoSPARQL > > > > > > Greg - apologies for being tardy on this one. It looks in good shape. > > > Did you hear from anyone after the request for feedback? > > > > > > This is two modules: geosparql-jena and geosparql-fuseki > > > > > > A suggestion for how to proceed if you have the time for 3.11.0 is that > > > we include these basically as-is and remove jena-spatial from Fuseki > > > which we have been signalling for a while. > > > > > > Suggestion: > > > > > >jena-geosparql > > >jena-fuseki/jena-fuseki-geospatial > > > > > > and under org.apache.jena.geosparql and > org.apache.jena.fuseki.geosparql > > > > > > It would have to be maven. > > > > > > Documentation: > > > This does not have to timed with the release though desirable to have > > > some instructions on the website. > > > > > > Looking the modules, it has its own specialised Fuseki incarnation with > > > command line arguments and also internally a system wide configuration. > > > maybe, later, we might want to merge the Fuseki setup but exactly how > > > and whether separate is better for users due to the specialised nature > > > can wait. Release should get feedback after it is incorporated - > > > "release early, release often". > > > > > > Greg - how does that sound? > > > > > > PMC - having more eyes on this would be helpful. > > > > > > If the timing is OK, we can work on details on the ticket JENA-664 (or > > > email on dev@). > > > > > > == JENA-1691 : Prometheus metrics > > > > > > This is getting there. We have the code worked out, the packaging needs > > > a bit of discussion; importantly it is missing L&N changes due to > > > BSD-binaries in the combined jars mean some L&N changes. > > > > > > == JENA-1690 : SurroundQueryParser > > > > > > Looks like this is ready and waiting for someone to merge it. > > > > > > > > > With all that, it looks like some things to sort out. > > > > > > We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with > > > whatever is ready, including getting things in and expect to further > > > refine, then advance the timing on 3.12.0. > > > > > > Thoughts? > > > > > > Andy > > >
Re: [VOTE] Apache Jena 3.11.0 RC1
Hi All, When building the source from the EDT (GMT -4) timezone, I get test failures in the o.a.j.sparql.expr.TestFunctions:localDateTime_2 test. Basically, the test is expecting the timezone value to be > -1, which would be fine for about half of the world, but that value could range anywhere from -14 * 60 to 14 * 60. In EDT, the value is -240, which doesn't pass the `> -1` test Aaron On Sat, Apr 20, 2019 at 7:37 AM Bruno P. Kinoshita wrote: > [ x ] +1 Approve the release > > Built on Linux with `mvn clean install -Pdev` using: > > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; > 2018-06-18T06:33:14+12:00) > Maven home: /opt/apache-maven-3.5.4 > Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: > /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: en_NZ, platform encoding: UTF-8 > OS name: "linux", version: "4.15.0-47-generic", arch: "amd64", family: > "unix" > > > + does everything work on Linux? > Yes > +does the tag/commit in the SCM contain reproducible sources? > Yes > ThanksBruno > > On Saturday, 20 April 2019, 7:40:00 am NZST, Andy Seaborne < > a...@apache.org> wrote: > > Hi, > > Here is a vote on a release of Apache Jena 3.11.0. > This is the first proposed release candidate. > > The deadline for the vote is Tuesday, 23rd April, 2019 at 17:00 UTC > > Release changes: > > 37 JIRA: > > https://s.apache.org/jena-3.11.0-jira > > == Changes of note: > > JENA-1691 : Metric services for Fuseki > Sean Ryan > > JENA-1664, JENA-1665, JENA-1673 > SDB improvements including performance of OPTIONAL, MINUS > Graham Triggs > > JENA-1686 > Set Dyadic#getL() and Dyadic#getR() return type to Graph > Jan Martin Keil > > JENA-1674 : Fix mishandling negative xsd:floats in TDB2 > > JENA-1644 : ParameterizedSparqlString Empty List fix > Greg Albiston > > Improvements to TDB1 and TDB2 handling bad I/O > during transaction commit. > > == Updates > > commons compress 1.17 -> 1.18 > libthrift 0.10.0 -> 0.12.0 > jsonld-java 0.12.1 -> 0.12.3 > Additionally, control the version of Jackson: 2.9.8 due to CVE's > fileupload 1.3.3 -> 1.4 > slf4j -> 1.7.25 -> 1.7.26 (CVE upgrade) > > new: > io.micrometer: 1.1.3 > and recursive dependencies: > org.hdrhistogram:HdrHistogram:jar:2.1.9 (BSD-2-Clause) > org.latencyutils:LatencyUtils:jar:2.0.3 (BSD-2-Clause) > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejena-1029 > > Proposed dist/ area: > https://dist.apache.org/repos/dist/dev/jena/ > > Keys: > https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): > https://github.com/apache/jena/commit/4b2f7f32c041 > > Git Commit Hash: > 4b2f7f32c0410cca6636b58a89b51d5eb56f247e > > Git Commit Tag: > jena-3.11.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open until at least > > Tuesday, 23rd April, 2019 at 17:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > > Andy > > Checking needed: > > + does everything work on Linux? > + does everything work on MS Windows? > + does everything work on OS X? > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive really be built? > (NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact > (both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: The state of jena+Java11
I think this can be fixed by setting the javadoc configuration to use Java 8 as the source. I submitted a PR to this effect here: https://github.com/apache/jena/pull/565 but please give that branch a real test on your local system before merging, I'm traveling at the moment and am not in a great position to run a full build. (Though running mvn javadoc:javadoc seems OK under JDK11) Aaron On Thu, Apr 25, 2019 at 9:07 AM Andy Seaborne wrote: > With the elephas change, I tried to build with java11 (producing java8 > byte code). > > We seem to be blocked by not being able to produce javadoc. > > The error is for each module: > """ > The code being documented uses modules but the packages defined in > https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module. > """ > > The block is: > >https://bugs.openjdk.java.net/browse/JDK-8212233 > > and I haven't found a workaround that works. (I am using Ubuntu dist > java, 11.0.3 which is claimed to have a backport of the fix). > > Anyone know anything about this? > > Andy >
Re: [VOTE] Apache Jena 3.11.0 RC2
[x] +1 Approve this release Tested building on OS X using Java 11 and Java 8 using this command: `$ mvn clean install -Pdev` Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac" and Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac" OSGi provisioning works with manual testing in Karaf 4.2.3 and via automated pax-exam-based tests in a downstream project. Checksums are good Signatures are good SCM tags are good. Thanks! Aaron On Mon, Apr 29, 2019 at 2:27 PM Andy Seaborne wrote: > Could we get a PMC vote please? > > So far > > +1 2 PMC, 1 community > > Andy > > On 24/04/2019 11:53, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on a release of Apache Jena 3.11.0. > > This is the second proposed release candidate. > > > > The deadline for the vote is Saturday, 27th April at 17:00 UTC > > > > Differences to RC1: > > > > * Fix for timezone test failure > > * Fix JENA-1705 for ParameterizedSpqralString > > > > Release changes: > > > > 38 JIRA: > > > > https://s.apache.org/jena-3.11.0-jira > > > > == Changes of note: > > > > JENA-1691 : Metric services for Fuseki > > Sean Ryan > > > > JENA-1664, JENA-1665, JENA-1673 > > SDB improvements including performance of OPTIONAL, MINUS > > Graham Triggs > > > > JENA-1686 > > Set Dyadic#getL() and Dyadic#getR() return type to Graph > >Jan Martin Keil > > > > JENA-1674 : Fix mishandling negative xsd:floats in TDB2 > > > > JENA-1644 : ParameterizedSparqlString Empty List fix > >Greg Albiston > > > > Improvements to TDB1 and TDB2 handling bad I/O > > during transaction commit. > > > > == Updates > > > > commons compress 1.17 -> 1.18 > > libthrift 0.10.0 -> 0.12.0 > > jsonld-java 0.12.1 -> 0.12.3 > > Additionally, control the version of Jackson: 2.9.8 due to CVE's > > fileupload 1.3.3 -> 1.4 > > slf4j -> 1.7.25 -> 1.7.26 (CVE upgrade) > > > > new: > > io.micrometer: 1.1.3 > > and recursive dependencies: > > org.hdrhistogram:HdrHistogram:jar:2.1.9 (BSD-2-Clause) > > org.latencyutils:LatencyUtils:jar:2.0.3 (BSD-2-Clause) > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1030 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/a13228f7 > > > > Git Commit Hash: > >a13228f7812a0d24f4242bfcae82ff2232a1ea58 > > > > Git Commit Tag: > >jena-3.11.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Saturday, 27th April at 17:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + does everything work on Linux? > > + does everything work on MS Windows? > > + does everything work on OS X? > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive really be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
Re: SHACL
Thank, Andy, I will likely have some data+shape resources in the coming weeks/months that I would like to test. Are there plans to add this code to Jena itself, or do you anticipate that it will be part of a separate repository? Best, Aaron On Mon, 8 Jul 2019 at 10:58, Andy Seaborne wrote: > I've got a SHACL validation engine working - it covers both the core and > sparql constraints of the W3C Specification. > > If anyone has data+shapes, I'll happily use them to run further tests. > > Status: passes the WG test suite except for some in > std/sparql/pre-binding/. Optional $shapesGraph and $currentShape are not > supported (more below) and the "unsupported" tests in pre-binding (some > of the rules seem overly restrictive) aren't run. > > AKA All valid shapes work, invalid shapes are "what you can get away > with". This is for future flexibility :-) > > None of the non-spec SHACL-AF is covered. > > API: > > As well as the operations to validate a graph using a given shapes graph > (command line or API), there is also a graph that rejects non-conforming > data in a graph transaction. > > Datasets: > > SHACL is defined to validate a single graph. To extend to validation of > a dataset, just one set for shapes for all graphs seems a little > restrictive. > > Some ideas -- https://afs.github.io/shacl-datasets.html > > $shapesGraph is for the case where data and shapes are in one dataset - > I'm not sure that's a very good idea because it imposes conditions on > extending SHACL to data datasets. > > Opportunities: > > There are possibilities for further work for deeper integration into > dataset update path: > > * Parallel execution - some shapes can be applied to an update stream > without reference to the data so can be done on a separate thread > outside the transaction. > > * Restricting the validation work needed - for some shapes > (not all, but it is a static analysis of shapes to determine which) > the updates can be tracked to only validate changes. There are ways to > write shapes that (1) apply globally to the data or (2) have indirect > data changes where just looking at the data does not tell you if a shape > might now report violations. > > There is some prototyping done but I got sidetracked by shacl-datasets.html > > Andy >
Re: [jena] 01/04: Build for wider range of JDKs on Travis
JDK 9 and 10 are EOL (there is really no need to test those). Java11 is a LTS edition, so it should definitely be tested. Java12 is the current non-LTS version under release, and Java13 will supersede Java12 in September. On Mon, 8 Jul 2019 at 15:30, Andy Seaborne wrote: > Rob, > > Aren't java9 and java10 now end-of-life? > > If so - do we need them in the general travis (merely because each adds > 15-20 mins). > > I use Travis for branch development - we can use Jekins to validate master. > > In the same vein - what about a 13 Early Access build on ASF Jenkins? > > Andy > > On 08/07/2019 10:16, rve...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > > > rvesse pushed a commit to branch master > > in repository https://gitbox.apache.org/repos/asf/jena.git > > > > commit f0bf5f317e0725fd7b375dfa83859692c79216e6 > > Author: Rob Vesse > > AuthorDate: Mon Apr 29 13:44:15 2019 +0100 > > > > Build for wider range of JDKs on Travis > > --- > > .travis.yml | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/.travis.yml b/.travis.yml > > index 7b39dcc..6b02e49 100644 > > --- a/.travis.yml > > +++ b/.travis.yml > > @@ -5,5 +5,8 @@ script: mvn -B clean install > > jdk: > > - openjdk8 > > - oraclejdk8 > > + - openjdk9 > > + - openjdk10 > > + - openjdk11 > > env: > > - JAVA_OPTS="-Xmx3072M -Xms512M -XX:+UseG1GC" > > >
Re: SHACL
> > > On 08/07/2019 16:28, Aaron Coburn wrote: > >> Thanks, Andy, I will likely have some data+shape resources in the coming > >> weeks/months that I would like to test. Are there plans to add this > >> code to > >> Jena itself, or do you anticipate that it will be part of a separate > >> repository? > > Is your comment a preference to have it as part of the Jena distribution? > > (Anything to test with at the moment?) > I was mostly curious about the plans for this code. I can't say that I have a strong preference: at the moment, I am primarily interested in having some code to test with. The fact that it is now in the Jena source tree will make this easier for me. Thanks, Aaron >> On Mon, 8 Jul 2019 at 10:58, Andy Seaborne wrote: > >> > >>> I've got a SHACL validation engine working - it covers both the core > and > >>> sparql constraints of the W3C Specification. > >>> > >>> If anyone has data+shapes, I'll happily use them to run further tests. > >>> > >>> Status: passes the WG test suite except for some in > >>> std/sparql/pre-binding/. Optional $shapesGraph and $currentShape are > not > >>> supported (more below) and the "unsupported" tests in pre-binding (some > >>> of the rules seem overly restrictive) aren't run. > >>> > >>> AKA All valid shapes work, invalid shapes are "what you can get away > >>> with". This is for future flexibility :-) > >>> > >>> None of the non-spec SHACL-AF is covered. > >>> > >>> API: > >>> > >>> As well as the operations to validate a graph using a given shapes > graph > >>> (command line or API), there is also a graph that rejects > non-conforming > >>> data in a graph transaction. > >>> > >>> Datasets: > >>> > >>> SHACL is defined to validate a single graph. To extend to validation of > >>> a dataset, just one set for shapes for all graphs seems a little > >>> restrictive. > >>> > >>> Some ideas -- https://afs.github.io/shacl-datasets.html > >>> > >>> $shapesGraph is for the case where data and shapes are in one dataset - > >>> I'm not sure that's a very good idea because it imposes conditions on > >>> extending SHACL to data datasets. > >>> > >>> Opportunities: > >>> > >>> There are possibilities for further work for deeper integration into > >>> dataset update path: > >>> > >>> * Parallel execution - some shapes can be applied to an update stream > >>> without reference to the data so can be done on a separate thread > >>> outside the transaction. > >>> > >>> * Restricting the validation work needed - for some shapes > >>> (not all, but it is a static analysis of shapes to determine which) > >>> the updates can be tracked to only validate changes. There are ways to > >>> write shapes that (1) apply globally to the data or (2) have indirect > >>> data changes where just looking at the data does not tell you if a > shape > >>> might now report violations. > >>> > >>> There is some prototyping done but I got sidetracked by > >>> shacl-datasets.html > >>> > >>> Andy > >>> > >> >
Re: [CANCELLED] [VOTE] Apache Jena 3.13.0 RC 1
I can also confirm this: the build succeeds from the git tag but not from the source artifact (due to the missing file in the SHACL module) Aaron On Tue, 24 Sep 2019 at 15:13, Andy Seaborne wrote: > Due to missing files in the source-release. > > Andy > > On 24/09/2019 13:51, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on a release of Apache Jena 3.13.0. > > This is the first proposed release candidate. > > > > There was a last minute upgrade of Jackson jars (core and databind) to > > 2.9.10 due to an alert from the GitHub security scan. > > > > The deadline for the vote is Friday, 27th Sept, 2019 at 20:00 UTC > > > > Release changes: > > > > == Major items > > > > JENA-1733: A SHACL engine > > JENA-1693: Add Aggregate Function MEDIAN and MODE (from Marco) > > JENA-1731: Fuseki endpoint configuration > > JENA-1695: DB storage refactoring > > JENA-1718: Remove jena-spatial from the build > > JENA-1760: Retire jena-maven-tools > > > > == JIRA > > > > Other JIRA: > > https://s.apache.org/jena-3.13.0-jira > > > > == Updates > > > > FasterXML jackson:: 2.9.9 -> 2.9.10 > > > > jsonld-java :: 0.12.3 -> 0.12.5 > > > > JENA-1754: Apache Commons Compress :: 1.18 -> 1.19 (Brad Hards) > > > > JENA-1756: Dependency updates. > > micrometer :: 1.1.3->1.2.1 > > Apache Commons Lang3 :: 3.4->3.9 > > Apache Commons CSV :: 1.5 -> 1.7 > > Apache HttpClient :: 4.5.5 -> 4.5.10 > > Apache Commons Collections4 :: 4.1 -> 4.4 > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1032 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/756447a1 > > > > Git Commit Hash: > >756447a17ee2b150503db6e2b342a276a2865b18 > > > > Git Commit Tag: > >jena-3.13.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Friday, 27th Sept, 2019 at 20:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive really be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
Re: [VOTE] Apache Jena 3.13.0 RC 2
Checksums and signatures all look good. The full source release builds (and tests) for me under both JDK8 and JDK11 OSGi provisioning works One issue I found -- and this isn't necessarily a blocker because it appears that it existed before: the jena-dboe-storage artifact has an empty Automatic-Module-Name header. That is, the header is present with no value (as opposed to there being no such header in the MANIFEST). As such, that means that any JPMS-based (JDK11 modules) build will have trouble with that module. It also appears that this issue existed in the 3.12 release; the reason I'm encountering it now is that the tdb2 module now depends on jena-dboe-storage instead of jena-dboe-trans-data: https://github.com/apache/jena/commit/340f4fbc38b58577e722c6e9762cd89195d43d0c#diff-57239f2bc267be000618f917613a89c9L44 I am happy to supply a patch to fix this. It's up to you whether you'd like that to go into the 3.13 release Cheers, Aaron On Wed, 25 Sep 2019 at 13:15, Andy Seaborne wrote: > [x] +1 Approve the release (binding) > > On 25/09/2019 18:15, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on a release of Apache Jena 3.13.0. > > This is the second proposed release candidate. > > > > There was a last minute upgrade of Jackson jars (core and databind) to > > 2.9.10 due to an alert from the GitHub security scan. > > > > The SHACL tests have been moved to have them added to source-release > > after the issue in RC 1. > > > > JENA-1763 :: commit : https://github.com/apache/jena/commit/adce00cf > > > > The deadline for the vote is Saturday, 28th Sept, 2019 at 20:00 UTC > > > > Release changes: > > > > == Major items > > > > JENA-1733: A SHACL engine > > JENA-1693: Add Aggregate Function MEDIAN and MODE (from Marco) > > JENA-1731: Fuseki endpoint configuration > > JENA-1695: DB storage refactoring > > JENA-1718: Remove jena-spatial from the build > > JENA-1760: Retire jena-maven-tools > > > > == JIRA > > > > Other JIRA: > > https://s.apache.org/jena-3.13.0-jira > > > > == Updates > > > > FasterXML jackson:: 2.9.9 -> 2.9.10 > > > > jsonld-java :: 0.12.3 -> 0.12.5 > > > > JENA-1754: Apache Commons Compress :: 1.18 -> 1.19 (Brad Hards) > > > > JENA-1756: Dependency updates. > > micrometer :: 1.1.3->1.2.1 > > Apache Commons Lang3 :: 3.4->3.9 > > Apache Commons CSV :: 1.5 -> 1.7 > > Apache HttpClient :: 4.5.5 -> 4.5.10 > > Apache Commons Collections4 :: 4.1 -> 4.4 > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1033 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/ec5b9011 > > > > Git Commit Hash: > >ec5b9011be4a6e9c8303bf8bce1e7d79d5a0eb6e > > > > Git Commit Tag: > >jena-3.13.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Saturday, 28th Sept, 2019 at 20:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive really be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
Re: [] Apache Jena 3.13.0 RC 2
That proposal seems sensible to me. These Java11 issues can be fixed in a 3.13.1 release. In that case: [x] +1 Approve this release (binding) Cheers, Aaron On Wed, 25 Sep 2019 at 16:36, Andy Seaborne wrote: > I'd like to go ahead and I offer to do a 3.13.1 to tidy up any rough edges. > > Reason: At this point, 3.13.0 RC 3 or 3.13.1 isn't much different in > terms of work needed from my side. I hope it isn't much on the > reviewers' side either. > > How does getting 3.13.0 out, wait for a short period of time to see if > anything turns up, then do 3.13.1 sound? > > By x.x.1, I mean specific changes only (fixes and safe/contained > changes), and certainly no new modules. > > I'd also like to find a way for more automated tests to catch things > early (won't we all?!). > > Andy > > On 9/25/19 9:00 PM, Aaron Coburn wrote: > > Checksums and signatures all look good. > > The full source release builds (and tests) for me under both JDK8 and > JDK11 > > OSGi provisioning works > > > > One issue I found -- and this isn't necessarily a blocker because it > > appears that it existed before: the jena-dboe-storage artifact has an > empty > > Automatic-Module-Name header. That is, the header is present with no > value > > (as opposed to there being no such header in the MANIFEST). As such, that > > means that any JPMS-based (JDK11 modules) build will have trouble with > that > > module. It also appears that this issue existed in the 3.12 release; the > > reason I'm encountering it now is that the tdb2 module now depends on > > jena-dboe-storage instead of jena-dboe-trans-data: > > > https://github.com/apache/jena/commit/340f4fbc38b58577e722c6e9762cd89195d43d0c#diff-57239f2bc267be000618f917613a89c9L44 > > > > I am happy to supply a patch to fix this. It's up to you whether you'd > like > > that to go into the 3.13 release > > > > Cheers, Aaron > > > > > > On Wed, 25 Sep 2019 at 13:15, Andy Seaborne wrote: > > > >> [x] +1 Approve the release (binding) > >> > >> On 25/09/2019 18:15, Andy Seaborne wrote: > >>> Hi, > >>> > >>> Here is a vote on a release of Apache Jena 3.13.0. > >>> This is the second proposed release candidate. > >>> > >>> There was a last minute upgrade of Jackson jars (core and databind) to > >>> 2.9.10 due to an alert from the GitHub security scan. > >>> > >>> The SHACL tests have been moved to have them added to source-release > >>> after the issue in RC 1. > >>> > >>> JENA-1763 :: commit : https://github.com/apache/jena/commit/adce00cf > >>> > >>> The deadline for the vote is Saturday, 28th Sept, 2019 at 20:00 UTC > >>> > >>> Release changes: > >>> > >>> == Major items > >>> > >>> JENA-1733: A SHACL engine > >>> JENA-1693: Add Aggregate Function MEDIAN and MODE (from Marco) > >>> JENA-1731: Fuseki endpoint configuration > >>> JENA-1695: DB storage refactoring > >>> JENA-1718: Remove jena-spatial from the build > >>> JENA-1760: Retire jena-maven-tools > >>> > >>> == JIRA > >>> > >>> Other JIRA: > >>> https://s.apache.org/jena-3.13.0-jira > >>> > >>> == Updates > >>> > >>> FasterXML jackson:: 2.9.9 -> 2.9.10 > >>> > >>> jsonld-java :: 0.12.3 -> 0.12.5 > >>> > >>> JENA-1754: Apache Commons Compress :: 1.18 -> 1.19 (Brad Hards) > >>> > >>> JENA-1756: Dependency updates. > >>> micrometer :: 1.1.3->1.2.1 > >>> Apache Commons Lang3 :: 3.4->3.9 > >>> Apache Commons CSV :: 1.5 -> 1.7 > >>> Apache HttpClient :: 4.5.5 -> 4.5.10 > >>> Apache Commons Collections4 :: 4.1 -> 4.4 > >>> > >>> Release Vote > >>> > >>> Everyone, not just committers, is invited to test and vote. > >>> Please download and test the proposed release. > >>> > >>> Staging repository: > >>> > https://repository.apache.org/content/repositories/orgapachejena-1033 > >>> > >>> Proposed dist/ area: > >>> https://dist.apache.org/repos/dist/dev/jena/ > >>> > >>> Keys: > >>> https://svn.apache.org/repos/asf/jena/dist/KEYS > >>> > >>> Git commit (browser URL): > >>> https://github.com
Re: Towards Jena 3.13.1
Next week works for me. Thanks, Aaron On Thu, Oct 3, 2019, 04:42 A. Soroka wrote: > I should be able to test on Linux and vote. > > (MacBook Pro battery bug got me, arg!) > > Adam > > On Thu, Oct 3, 2019, 9:38 AM Rob Vesse wrote: > > > I'm on a work trip next week and won't have any free time (was on > vacation > > for last weeks vote as well!) > > > > Rob > > > > On 03/10/2019, 09:34, "Andy Seaborne" wrote: > > > > Hi there, > > > > I just want to check whether getting the votes for 3.13.1 is going to > > work. > > > > If it's early next week, are you able to vote? > > > > Andy > > > > https://s.apache.org/jena-3.13.1-jira > > > > which is 3 tickets at the moment, no dependency changes: > > > > JENA-1764 > > Fix missing and duplicate Automatic-Module-Name metadata > > > > JENA-1766 > > Fuseki Web interface endpoint mechanism not working > > > > JENA-1767 > > Enable clear out of all TDB1 location-related state. > > > > On 30/09/2019 12:26, Andy Seaborne wrote: > > > See the vote thread for 3.13.0 RC2 - the automatic module names for > > some > > > modules are wrong. Aaron has fixed this but the release will > > interact > > > badly with Java module usage. > > > > > > As well as the automatic module names, there is now JENA-1766 > > (problems, > > > and solution, with the Fuseki admin UI). This is in the SNAPSHOT > > builds > > > for testing. > > > > > > I think it is better to wait a few days at least to see if anything > > else > > > comes up but otherwise I'm hoping for getting this out sooner > rather > > > than later. > > > > > > The master branch is still 3.14.0-SNAPSHOT - to make this a proper > > > x.x.1, could people hold off from merging anything that aren't bug > > fixes. > > > > > > If it turns out to be a longer wait, we can branch and release from > > the > > > branch but if we can leave the version flip until the last moment > > (so a > > > few hours of reverted version), do it on master and release from > > master > > > then master has the release history. > > > > > > Andy > > > > > > > > > > > > >
Re: [VOTE] Apache Jena 3.13.1 RC 1.
[x] +1 Approve the release (binding) The signatures and checksums are all good LICENSE and NOTICE files are present I was able to do a full build (mvn verify install) from the source artifact with Java 1.8.0_221 The Java11 automatic module names are all correct and I was able to successfully test Jena in a Java11 environment OSGi provisioning works with Karaf 4.2.6 Thanks, Aaron On Sun, 6 Oct 2019 at 17:53, Andy Seaborne wrote: > [x] +1 Approve the release (binding) > > Andy > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1034 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/987b59e240 > > > > Git Commit Hash: > >987b59e2405f2e5853f5550219b932a5fb7bb86c > > > > Git Commit Tag: > >jena-3.13.1 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Thursday, 10th October 2019 at 06:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. >
Re: Jena next
I would be very interested in discussing the high level Java API and how it could be simplified. It might also be worthwhile to look into the overall package/jar structure. This will help for both OSGi and JPMS support. Regarding the Java14/JPMS target, I assume this means that the Jena code can be compiled and run on a Java14 environment and/or used on the module path in a JPMS-enabled application (and *not* that all downstream applications must use one of the newer Java runtimes). That is, would the compiler target and source still be Java8? Cheers, Aaron On Wed, 13 Nov 2019 at 14:18, Andy Seaborne wrote: > I'd like to start a discussion on where the project might go longer term. > > This can be specific areas, overall design, about project processes, > anything. > > If we are going to do a major change, Jena4, what preparation for that > can be done? (e.g. deprecation and signalling in Jena3, before the > change happens). > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4 > need not be that big - we can have Jena5 etc. > > I'll put some technical points in a separate email. > > I would put on the list: > > * How has the world changed? What should the project produce? > * Target audience: for developers of Jena, while Jena3 is for users. > * Target: Java14, JPMS. > * Clear-up not easily done with perfect compatibility. > * Simpler. There are APIs and packages entangled due to history. > > To the lurkers :-) > > Feedback and specific feature requests are welcome. But before you "go > shopping", you may wish to factor in that every feature needs effort to > do it. The better place to be is that an application can get what it > needs to do, not whether the Jena system has every feature built-in. > > Andy >
Re: Towards Jena 3.14.0
I will have time to review any release candidates between now and Jan 20. Cheers, Aaron On Tue, 7 Jan 2020 at 08:37, Andy Seaborne wrote: > It's coming up to time to look at Jena 3.14.0. v3.13.1 was 2019-10-11. > > I have time between now and January 19th to do a release or to work with > anyone who is interested in performing a release. January 20th and after > is likely to be busy due to new employment. > > Andy > > == Contributions and notable JIRA > > Pavel Mikhailovskii: > JENA-1787: SHACL improvement > JENA-1786: DatasetGraphMonitor exposes unwrapped graphs > JENA-1785: TDB2 bug fix > JENA-1784: CacheSimple doesn't check keys for equality > > Ken Treimann: > JENA-1781: Thrift upgrade to 0.13.0 for a CVE. > > Georg Schmidt-Dumont: > JENA-1796: Add missing DV for XSD DateTimeStamp data type > > Adrian Wilke: > JENA-1792: DCat vocabulary update to DCat2 > > > JENA-1779: Update to Jackson 2.10.1 > > 2.10 has a design change to remove the 2.9.x attack point. > Hopefully, moving to 2.10 will mean the end of recurring CVE's for Jackson. > > == JIRA > > https://s.apache.org/jena-3.14.0-jira > > 36 currently. > >
Re: [VOTE] Split off GH PR email traffic to a new list.
+1 Thanks, Aaron On Tue, 7 Jan 2020 at 08:42, wrote: > +1. This would be great! > > Adam > > On Tue, Jan 7, 2020, 8:36 AM Andy Seaborne wrote: > > > Happy 2020 everyone. > > > > From the [DISCUSS] around: > > > > > > > https://lists.apache.org/thread.html/12988132a86780d1fc14c6f893099cac50875e1d04a360d6046fdc0a%40%3Cdev.jena.apache.org%3E > > > > here is the formal vote: > > > > Proposal: > > This is the minimal proposal. > > > > > > Ask INFRA for a new mailing list, "pr@", and route github repo email > > currently going to dev@ to that list. > > > > > > Please vote > > > > [ ] +1 Approve the proposal > > [ ] 0 Don't care > > [ ] -1 Don't make the change because ... > > > > > > This vote is open to at least: > > > > Friday 2020-01-10 18:00 UTC. > > > > (for additional discussion either the [DISCUSS] thread or change > > "[VOTE]" to "[]". > > > > Andy > > >
Re: [VOTE] Apache Jena 3.14.0 RC 1
This might be good to split off into a separate issue (and it doesn't necessarily need to block the release), but I'm finding that, when using TDB2 with this release candidate in a concurrent write context, I start encountering a lot of errors. And those errors are definitely not present with 3.13.1. Specifically, the issue seems to be related to contention over the TDB2 ThreadBufferingCache. That buffering cache is present in the 3.13.1 release, and I'm not entirely sure what changed with 3.14.0 that would trigger these errors, but this is the relevant part of the stack trace: Caused by: org.apache.jena.tdb2.TDBException: ThreadBufferingCache: already buffering at org.apache.jena.tdb2.store.nodetable.ThreadBufferingCache.enableBuffering(ThreadBufferingCache.java:88) at org.apache.jena.tdb2.store.nodetable.NodeTableCache.updateStart(NodeTableCache.java:352) at org.apache.jena.tdb2.store.nodetable.NodeTableCache.notifyTxnStart(NodeTableCache.java:319) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$notifyBegin$14(TransactionCoordinator.java:915) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$listeners$0(TransactionCoordinator.java:207) at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.listeners(TransactionCoordinator.java:207) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.notifyBegin(TransactionCoordinator.java:915) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:553) at org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:509) at org.apache.jena.dboe.transaction.txn.TransactionalBase.begin(TransactionalBase.java:110) at org.apache.jena.dboe.storage.system.DatasetGraphStorage.begin(DatasetGraphStorage.java:59) at org.apache.jena.sparql.core.DatasetGraphWrapper.begin(DatasetGraphWrapper.java:233) at org.apache.jena.sparql.core.DatasetImpl.begin(DatasetImpl.java:116) at org.apache.jena.system.Txn.exec(Txn.java:76) at org.apache.jena.system.Txn.executeWrite(Txn.java:125) at org.apache.jena.rdfconnection.RDFConnectionLocal.update(RDFConnectionLocal.java:80) Effectively, I get that error at the first time a client attempts to concurrently write to the TDB2 store. Subsequent attempts just hang. Cheers, Aaron On Mon, 13 Jan 2020 at 11:23, Andy Seaborne wrote: > Hi, > > Here is a vote on the release of Apache Jena 3.14.0 > This is the first proposed release candidate. > > Changes: > > https://s.apache.org/jena-3.14.0-jira > > Release Vote > > Everyone, not just committers, is invited to test and vote. > Please download and test the proposed release. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachejena-1035 > > Proposed dist/ area: >https://dist.apache.org/repos/dist/dev/jena/ > > Keys: >https://svn.apache.org/repos/asf/jena/dist/KEYS > > Git commit (browser URL): >https://github.com/apache/jena/commit/19d42a5 > > Git Commit Hash: >19d42a57a9debc675047b2d1ce9769979c43e7d8 > > Git Commit Tag: >jena-3.14.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This vote will be open until at least > > Thursday, 16th January 2020 at 187:00 UTC > > If you expect to check the release but the time limit does not work > for you, please email within the schedule above with an expected time > and we can extend the vote period. > > Thanks, > >Andy > > Checking needed: > > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? > > + can the source archive really be built? >(NB This requires a "mvn install" first time) > + is there a correct LICENSE and NOTICE file in each artifact >(both source and binary artifacts)? > + does the NOTICE file contain all necessary attributions? > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? > + does the tag/commit in the SCM contain reproducible sources? >
Re: [] Apache Jena 3.14.0 RC 1
Hi Andy, I'll dig a little deeper into what's going on and will put together a reproducible test case for this. I first wanted to find out if it might be something obvious. Thanks, Aaron On Wed, 15 Jan 2020 at 13:44, Andy Seaborne wrote: > Hi Aaron, > > Could you say some more about how the concurrent writes are happening > and what they are doing? Just from the stacktrace I haven't managed to > write a test case. > > My guess is that another transaction is finishing a commit about the > same time. But if the other transaction is mid-processing then its > something else. > > If you are able to putting in a JVM-suspend breakpoint at > ThreadBufferingCache:88 and capture a thread dump, that would be very > helpful - I realise it's not always easy to get up. > > Andy > > > > On 15/01/2020 16:55, Aaron Coburn wrote: > > This might be good to split off into a separate issue (and it doesn't > > necessarily need to block the release), but I'm finding that, when using > > TDB2 with this release candidate in a concurrent write context, I start > > encountering a lot of errors. And those errors are definitely not present > > with 3.13.1. Specifically, the issue seems to be related to contention > over > > the TDB2 ThreadBufferingCache. That buffering cache is present in the > > 3.13.1 release, and I'm not entirely sure what changed with 3.14.0 that > > would trigger these errors, but this is the relevant part of the stack > > trace: > > > > Caused by: org.apache.jena.tdb2.TDBException: ThreadBufferingCache: > already > > buffering > > at > > > org.apache.jena.tdb2.store.nodetable.ThreadBufferingCache.enableBuffering(ThreadBufferingCache.java:88) > > at > > > org.apache.jena.tdb2.store.nodetable.NodeTableCache.updateStart(NodeTableCache.java:352) > > at > > > org.apache.jena.tdb2.store.nodetable.NodeTableCache.notifyTxnStart(NodeTableCache.java:319) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$notifyBegin$14(TransactionCoordinator.java:915) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$listeners$0(TransactionCoordinator.java:207) > > at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.listeners(TransactionCoordinator.java:207) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.notifyBegin(TransactionCoordinator.java:915) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:553) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:509) > > at > > > org.apache.jena.dboe.transaction.txn.TransactionalBase.begin(TransactionalBase.java:110) > > at > > > org.apache.jena.dboe.storage.system.DatasetGraphStorage.begin(DatasetGraphStorage.java:59) > > at > > > org.apache.jena.sparql.core.DatasetGraphWrapper.begin(DatasetGraphWrapper.java:233) > > at org.apache.jena.sparql.core.DatasetImpl.begin(DatasetImpl.java:116) > > at org.apache.jena.system.Txn.exec(Txn.java:76) > > at org.apache.jena.system.Txn.executeWrite(Txn.java:125) > > at > > > org.apache.jena.rdfconnection.RDFConnectionLocal.update(RDFConnectionLocal.java:80) > > > > Effectively, I get that error at the first time a client attempts to > > concurrently write to the TDB2 store. Subsequent attempts just hang. > > > > Cheers, > > Aaron > > > > > > > > > > > > On Mon, 13 Jan 2020 at 11:23, Andy Seaborne wrote: > > > >> Hi, > >> > >> Here is a vote on the release of Apache Jena 3.14.0 > >> This is the first proposed release candidate. > >> > >> Changes: > >> > >> https://s.apache.org/jena-3.14.0-jira > >> > >> Release Vote > >> > >> Everyone, not just committers, is invited to test and vote. > >> Please download and test the proposed release. > >> > >> Staging repository: > >> > https://repository.apache.org/content/repositories/orgapachejena-1035 > >> > >> Proposed dist/ area: > >> https://dist.apache.org/repos/dist/dev/jena/ > >> > >> Keys: > >> https://svn.apache.org/repos/asf/jena/dist/KEYS > >> > >> Git commit (browser URL): > >> https://github.com/apache/jena/commit/19d42a5 > >> > >> Git Commit Hash: > >> 19d42a57a9debc675047b2d1ce9769979c43e
Re: [] Apache Jena 3.14.0 RC 1
Hi Andy, It appears that there is a subtle race condition in how the ThreadBufferingCache coordinates write access to the underlying storage. In debugging this, I made the following changes https://github.com/apache/jena/compare/feature/debug_concurrent_writes Effectively, I added a Semaphore object to the class. With that change, my test suite passes (this is the Trellis codebase, in case you are wondering). I also checked for any significant changes to the performance from 3.13.1 to 3.14.0 (with this change in place), and after running the tests repeatedly, I didn't see any appreciable performance change one way or the other. If this seems like a reasonable adjustment to that class, I can write up a JIRA issue and submit this as a PR. Best, Aaron On Wed, 15 Jan 2020 at 14:25, Aaron Coburn wrote: > Hi Andy, > I'll dig a little deeper into what's going on and will put together a > reproducible test case for this. I first wanted to find out if it might be > something obvious. > > Thanks, > Aaron > > On Wed, 15 Jan 2020 at 13:44, Andy Seaborne wrote: > >> Hi Aaron, >> >> Could you say some more about how the concurrent writes are happening >> and what they are doing? Just from the stacktrace I haven't managed to >> write a test case. >> >> My guess is that another transaction is finishing a commit about the >> same time. But if the other transaction is mid-processing then its >> something else. >> >> If you are able to putting in a JVM-suspend breakpoint at >> ThreadBufferingCache:88 and capture a thread dump, that would be very >> helpful - I realise it's not always easy to get up. >> >> Andy >> >> >> >> On 15/01/2020 16:55, Aaron Coburn wrote: >> > This might be good to split off into a separate issue (and it doesn't >> > necessarily need to block the release), but I'm finding that, when using >> > TDB2 with this release candidate in a concurrent write context, I start >> > encountering a lot of errors. And those errors are definitely not >> present >> > with 3.13.1. Specifically, the issue seems to be related to contention >> over >> > the TDB2 ThreadBufferingCache. That buffering cache is present in the >> > 3.13.1 release, and I'm not entirely sure what changed with 3.14.0 that >> > would trigger these errors, but this is the relevant part of the stack >> > trace: >> > >> > Caused by: org.apache.jena.tdb2.TDBException: ThreadBufferingCache: >> already >> > buffering >> > at >> > >> org.apache.jena.tdb2.store.nodetable.ThreadBufferingCache.enableBuffering(ThreadBufferingCache.java:88) >> > at >> > >> org.apache.jena.tdb2.store.nodetable.NodeTableCache.updateStart(NodeTableCache.java:352) >> > at >> > >> org.apache.jena.tdb2.store.nodetable.NodeTableCache.notifyTxnStart(NodeTableCache.java:319) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$notifyBegin$14(TransactionCoordinator.java:915) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.lambda$listeners$0(TransactionCoordinator.java:207) >> > at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.listeners(TransactionCoordinator.java:207) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.notifyBegin(TransactionCoordinator.java:915) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:553) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:509) >> > at >> > >> org.apache.jena.dboe.transaction.txn.TransactionalBase.begin(TransactionalBase.java:110) >> > at >> > >> org.apache.jena.dboe.storage.system.DatasetGraphStorage.begin(DatasetGraphStorage.java:59) >> > at >> > >> org.apache.jena.sparql.core.DatasetGraphWrapper.begin(DatasetGraphWrapper.java:233) >> > at org.apache.jena.sparql.core.DatasetImpl.begin(DatasetImpl.java:116) >> > at org.apache.jena.system.Txn.exec(Txn.java:76) >> > at org.apache.jena.system.Txn.executeWrite(Txn.java:125) >> > at >> > >> org.apache.jena.rdfconnection.RDFConnectionLocal.update(RDFConnectionLocal.java:80) >> > >> > Effectively, I get that error at the first time a client attempts to >> > concurrently write to the TDB2 store. Subsequent attempts just hang. >
Re: [VOTE] Apache Jena 3.14.0 RC 2
+1 (binding) Checked signatures Github tag matches Built from github tag and source release with both JDK 8 and 11 Checked JDK 11 (module) compatibility Checked OSGi artifacts The fix for JENA-1817 addressed the issue I reported earlier Aaron On Thu, 16 Jan 2020 at 12:52, Andy Seaborne wrote: > +1 > > Andy > > On 16/01/2020 17:34, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on the release of Apache Jena 3.14.0 > > This is the second proposed release candidate. > > > > The deadline is only 72hours in case there are enough +1 votes and I can > > do the final stage on Sunday - otherwise, it is likely to be mid next > week. > > > > Changes from RC1: > > > > Fix for JENA-1817 > > https://github.com/apache/jena/commit/08ca0b83 > > > > Changes for 3.14.0: > > > > https://s.apache.org/jena-3.14.0-jira > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1036 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/d0abcd14 > > > > Git Commit Hash: > >d0abcd14f82c36045a3c047941a6518f3bdb56ce > > > > Git Commit Tag: > >jena-3.14.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Sunday, 19th January 2020 at 18:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive really be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
Re: Towards Java 3.15.0
I did some initial testing of the current master branch, and generally it looks great. It builds fine with JDK 8 and 11; all tests pass. I tried using those artifacts in some downstream code, and all looks good (including with Java 11 JPMS). The only possible issue I encountered was with the OSGi deployment. In Karaf 4.2.6 and later, the `feature:install jena` command works if I manually add a javax.annotation bundle (either from jakarta or the regular javax dependency). Given that this is a platform api and downstream users might have an opinion about which artifact to use for this, it might make sense to leave this as-is. It is trivial for downstream users to work around this. The one thing that should probably be fixed before a release is that, in Karaf 4.2.7 and later, the log4j2 dependency has to be manually added in order to start up the Jena feature. Since log4j2 is a particular logging implementation, I suspect that is really should be excluded from the OSGi bundle (as `org.apache.log` currently is). If that seems right, I could supply a PR. Aaron On Sun, 19 Apr 2020 at 16:40, Andy Seaborne wrote: > I'm sending this out a little early because of wanting to give warning > of the logging change before release, and generally get people to try > dev builds before we formally put out a release. > > Draft message for logging to come after this email. > > Outstanding: > * JENA-1837: MaxBasicQueries for Lucene > > For JENA-1837, I don't see any reason not to merge it but it would be > good for one of the reviewers to approve it. > > * Documentation for experimental RDF* > > Tickets: > https://s.apache.org/jena-3.15.0-jira > > Andy > > > Major changes: > > While logging should be largely an invisible change, there are possible > impacts. > > API-using code has had to have its own slf4j setup for sometime (we can > recommend moving to log4j2). If it uses Jena's LogCtl, there might be a > need to adjust. > > Fuseki or command line might be using a custom log4j1 setup (maybe > custom log4j.properties or log4j1 log routing). > > I think sending a message user@ now to alter people is worth doing. > > > Features: > > RDF* - experimental, in-memory only. > > (Doing TDB may happen, may not - there are two places to change, node > storage and the basic graph pattern solver. The latter in the same way > that StageGeneratorGenericStar works.) > > There have been quite a few contributions. > > > This release: > > > -- Upgrades > > JENA-1812: Update Commons Codec 1.13 -> 1.14 > > JENA-1883: Commons Lang3 : 3.9 -> 3.10 > > JENA-1839: Update Commons CSV 1.7 -> 1.8 > > JENA-1005: Update slf4j 1.7.26 -> 1.7.30 > > JENA-1850: Commons compress 1.19 -> 1.20 > > JENA-1836: Shiro: 1.2.6 -> 1.5.0 > CVE-2019-12422 > > JENA-1850: Jetty: 9.4.12.v20180830 -> 9.4.26.v20200117 > > JENA-1851: Lucene: 7.4.0 -> 7.7.2 > (Not -> 8.4.1) > > jena-es: ElasticSearch 6.4.2 -> ES 6.8.6 for Lucene 7.7.x > (Not -> ES 7.6.0 for Lucene 8.4.x) > > JENA-1829: Apache Parent POM to v23. > > -- Jena-1005: Logging > > Separate message > > -- Website > > With the help of Roy Lenferink, the production of the Apache Jena > website has moved from using svn and Apache's custom CMS to being stored > in git and using Hugo. > > The website source is https://github.com/apache/jena-site > > One change is that "Improve this page" has become "Edit this page". > > Proposed changes to the website can be made with git pull requests. > > Many thanks to Roy for nudging us to make this migration. > > -- Contributions and Notable JIRA > > JENA-1881: Experimental support for RDF* > This is limited to in-memory storage. > > JENA-1005: Logging > (separate message) > > JENA-1884: Removed JenaUUID > > JENA-1827: Use ConcurrentHashMap in TypeMapper > Simon Fell > > JENA-1835: > Capture and expose lexicalForm and dataType in DatatypeFormatException > Simon Fell > > JENA-1826: use plain RDF/XML in Fuseki RDF responses > CONSTRUCT/DESCRIBE RDF/XML output change > > JENA-1831: > Fix SDB transform issue with using UNION in restricting a query > Graham Triggs > > JENA-1855 : TriG parser fix > Claus Stadler > > JENA-1858 : SERVICE blocks after 5 attempts > Claus Stadler > > > JENA-1862: Improvements to Query.cloneQuery > Claus Stadler > > JENA-1868, JENA-1869 : TDB2 issues > Bernhard Stiftner > > JENA-1846: Fuseki CORS in Fuseki main > > JENA-1864: > Fix for @base output in TURTLE_BLOCKS and TURTLE_FLAT formats. > Viresh Gupta > > JENA-1878: Switch to using https://prefix.cc > David Fichtmueller > >
Re: [VOTE] Apache Jena 3.15.0 RC 1
+1 (binding) Hashes are good Signatures are good Built successfully from release tag on SCM (using JDK 8) Built successfully from source artifact (using JDK 11) Deployed successfully into Karaf 4.2.8 Verified that Jena 3.15 works in JPMS mode under Java 11 Successfully tested the new commons-rdf implementation All the artifacts have NOTICE and LICENSE files Aaron On Fri, 15 May 2020 at 11:55, Andy Seaborne wrote: > +1 > > Andy > > On 15/05/2020 15:50, Andy Seaborne wrote: > > Hi, > > > > Here is a vote on the release of Apache Jena 3.15.0 > > This is the first proposed release candidate. > > > > The deadline is Tuesday, 19th May 2020 at 06:00 UTC > > > > Dependency changes: > > > > JENA-1829: Apache Parent POM to v23. > > JENA-1812: Update Commons Codec 1.13 -> 1.14 > > JENA-1883: Commons Lang3 : 3.9 -> 3.10 > > JENA-1839: Update Commons CSV 1.7 -> 1.8 > > > > JENA-1005 > > Update slf4j 1.7.26 -> 1.7.30 > >new : org.apache.logging.log4j2 version 2.13.1 > >Remove log4j1 > > > > JENA-1850: Commons compress 1.19 -> 1.20 > > > > JENA-1836: Shiro: 1.2.6 -> 1.5.1 (CVE-2019-12422) > > JENA-1850: Jetty: 9.4.12.v20180830 -> 9.4.26.v20200117 > > JENA-1851: Lucene: 7.4.0 -> 7.7.2 (Not -> 8.4.1) > > ElasticSearch 6.4.2 -> ES 6.8.6 for Lucene 7.7.x > > (Not -> ES 7.6.0 for Lucene 8.4.x) > > > > Changes for 3.15.0: > > > > https://s.apache.org/jena-3.15.0-jira > > > > Release Vote > > > > Everyone, not just committers, is invited to test and vote. > > Please download and test the proposed release. > > > > Staging repository: > >https://repository.apache.org/content/repositories/orgapachejena-1037 > > > > Proposed dist/ area: > >https://dist.apache.org/repos/dist/dev/jena/ > > > > Keys: > >https://svn.apache.org/repos/asf/jena/dist/KEYS > > > > Git commit (browser URL): > >https://github.com/apache/jena/commit/a59b6b103c > > > > Git Commit Hash:@@ > >a59b6b103c8b109fbbdc15f9269fab6eebfc132c > > > > Git Commit Tag: > >jena-3.15.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > This vote will be open until at least > > > > Tuesday, 19th May 2020 at 06:00 UTC > > > > If you expect to check the release but the time limit does not work > > for you, please email within the schedule above with an expected time > > and we can extend the vote period. > > > > Thanks, > > > >Andy > > > > Checking needed: > > > > + are the GPG signatures fine? > > + are the checksums correct? > > + is there a source archive? > > > > + can the source archive really be built? > >(NB This requires a "mvn install" first time) > > + is there a correct LICENSE and NOTICE file in each artifact > >(both source and binary artifacts)? > > + does the NOTICE file contain all necessary attributions? > > + have any licenses of dependencies changed due to upgrades? > > if so have LICENSE and NOTICE been upgraded appropriately? > > + does the tag/commit in the SCM contain reproducible sources? >
[jira] [Commented] (JENA-1948) Consider using TItanium library for JSON-LD 1.1 support
[ https://issues.apache.org/jira/browse/JENA-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183648#comment-17183648 ] Aaron Coburn commented on JENA-1948: It would definitely be worth looking at Titanium. One important consideration, though, is that Titanium requires Java 11 (it uses the built-in Java HTTP client rather than depending on Apache HttpClient). And if Jena depends on Titanium, then Jena would need to also require Java 11. > Consider using TItanium library for JSON-LD 1.1 support > --- > > Key: JENA-1948 > URL: https://issues.apache.org/jira/browse/JENA-1948 > Project: Apache Jena > Issue Type: Wish > Components: RIOT >Reporter: Didac >Priority: Major > > Since there is finally a [JSON-LD 1.1 recommendation > release|[https://www.w3.org/TR/json-ld11/]] and Json-LD java is not fully > supporting JSON-LD 1.1 (plus it seems to be looking for maintainers) maybe is > time to take a look to the other project out there that supports JSON-LD 11 > in Java: [https://github.com/filip26/titanium-json-ld] > The coverage is pretty good. I haven't seen any performance comparison > though. And the project is very recent, but worth it to take a loot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-2112) ShEx engine
[ https://issues.apache.org/jira/browse/JENA-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354117#comment-17354117 ] Aaron Coburn commented on JENA-2112: ShEx comes from a W3C community group report: [https://shex.io/shex-semantics/] I would be very interested in having a ShEx based engine in Jena. I would also be happy to contribute to such an effort. AFAIK, the only Java-based ShEx engine is at [https://github.com/iovka/shex-java] which works but doesn't have a great license (LGPL) > ShEx engine > --- > > Key: JENA-2112 > URL: https://issues.apache.org/jira/browse/JENA-2112 > Project: Apache Jena > Issue Type: Improvement >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-2121) Can't use jena-core, jena-iri in modular runtime-image
[ https://issues.apache.org/jira/browse/JENA-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366694#comment-17366694 ] Aaron Coburn commented on JENA-2121: Jena releases jars with Automatic-Module-Name metadata, which should be sufficient. I have used these Jena components for several years now in a Java 11-based JPMS build. I do not believe the solution is necessarily to modify the Jena code. Are you certain that your module-info.java file is complete? Here is a reference: https://github.com/trellis-ldp/trellis/blob/main/components/jena/src/main/java/module-info.java#L24-L27 > Can't use jena-core, jena-iri in modular runtime-image > -- > > Key: JENA-2121 > URL: https://issues.apache.org/jira/browse/JENA-2121 > Project: Apache Jena > Issue Type: Bug > Components: Core, IRI > Environment: Java 11 >Reporter: Robin Tissot >Priority: Critical > > Hello, > I'm trying to create a runtime-image to distribute an Java 11 application > which is using jena-core and jena-iri using jlink but jlink command give me > error "automatic module cannot be used with jlink: org.apache.jena.core". > So I use moditect-maven-plugin to fix this error, this plugin consists of > adding module descriptors to existing JAR files, and I created module > descriptors of jena-core and jena-iri using jdeps command-line tool. This fix > my error with jlink but now I have an error when launching the runtime-image: > "java.util.ServiceConfigurationError: > org.apache.jena.sys.JenaSubsystemLifecycle: module org.apache.jena.core does > not declare 'uses' ". > My guess is the solution should be adding a complete module-info.java file in > jena modules. > Here is a minimal project showing the problem : > [https://github.com/Trobiun/JenaSample] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1948) Consider using Titanium library for JSON-LD 1.1 support
[ https://issues.apache.org/jira/browse/JENA-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386941#comment-17386941 ] Aaron Coburn commented on JENA-1948: Starting with a reader makes a lot of sense. I have some code that currently implements the bridge between a RIOT reader and a Titanium parser, portions of which are generic enough to go into Jena. In the process of working with Titanium, here is what I have found. # The currently released version of Titanium requires JakartaEE 9 (`import jakarta.json...`), which is too new for the frameworks we use, so we rely on Titanium version 0.8.6. Not everyone would necessarily have that restriction, but it may be presumptuous to think that everyone can immediately upgrade to the latest JEE. And unfortunately, the Titanium package structure is different between 0.8 and 1.x, so one can't just use maven exclusions to pick the right dependencies. As such, perhaps it would make senst to have a `jena-jsonld` and a `jena-jsonld-jee8` module? # I have found it very useful to be able to customize the document loader (esp. for Titanium 0.8.6), so as long as the Jena interfaces make this possible, that would be great. Effectively, what I've done is to build up a `JsonLdParser11` class that implements the `ReaderRIOTFactory` and then I bind that to `Lang.JSONLD` via `RDFParserRegistry::registerLangTriples` and `RDFParserRegistry::registerLangQuads` I like the idea of creating a `Lang.JSONLD_11` type. I would also be happy to contribute a generalized version of what I have for Jena > Consider using Titanium library for JSON-LD 1.1 support > --- > > Key: JENA-1948 > URL: https://issues.apache.org/jira/browse/JENA-1948 > Project: Apache Jena > Issue Type: Wish > Components: JSON-LD, RIOT >Reporter: Didac >Priority: Major > Labels: First > > Since there is finally a [JSON-LD 1.1 recommendation > release|https://www.w3.org/TR/json-ld11/] and Json-LD java is not fully > supporting JSON-LD 1.1 (plus it seems to be looking for maintainers) maybe is > time to take a look to the other project out there that supports JSON-LD 11 > in Java: [https://github.com/filip26/titanium-json-ld] > The coverage is pretty good. I haven't seen any performance comparison > though. And the project is very recent, but worth taking a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1948) Consider using Titanium library for JSON-LD 1.1 support
[ https://issues.apache.org/jira/browse/JENA-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395514#comment-17395514 ] Aaron Coburn commented on JENA-1948: For me, the principal use case involves reading and signing [Verifiable Credentials|https://www.w3.org/TR/vc-data-model/] documents, but there seem to be more and more JSON-LD 1.1 use cases emerging all the time. > Consider using Titanium library for JSON-LD 1.1 support > --- > > Key: JENA-1948 > URL: https://issues.apache.org/jira/browse/JENA-1948 > Project: Apache Jena > Issue Type: Wish > Components: JSON-LD, RIOT >Reporter: Didac >Priority: Major > Labels: First > > Since there is finally a [JSON-LD 1.1 recommendation > release|https://www.w3.org/TR/json-ld11/] and Json-LD java is not fully > supporting JSON-LD 1.1 (plus it seems to be looking for maintainers) maybe is > time to take a look to the other project out there that supports JSON-LD 11 > in Java: [https://github.com/filip26/titanium-json-ld] > The coverage is pretty good. I haven't seen any performance comparison > though. And the project is very recent, but worth taking a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JENA-1263) Configure HTTP client to follow 303 redirects
Aaron Coburn created JENA-1263:
--
Summary: Configure HTTP client to follow 303 redirects
Key: JENA-1263
URL: https://issues.apache.org/jira/browse/JENA-1263
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Affects Versions: Jena 3.1.1
Reporter: Aaron Coburn
Priority: Minor
Fix For: Jena 3.2.0
When calling RDFDataMgr.read(Model model, String uri), the underlying HTTP
client does not appear to follow 303 redirects. For example:
Model m = createDefaultModel();
RDFDataMgr.read(m, "http://purl.org/dc/terms/";);
org.apache.jena.riot.RiotException: Failed to determine the content type:
(URI=http://purl.org/dc/terms/ : stream=text/html)
A work-around is to add a static block with a custom HTTP client like so:
static {
HttpOp.setDefaultHttpClient(HttpClientBuilder.create().setRedirectStrategy(new
LaxRedirectStrategy()).build());
}
By default the Apache HTTP client follows 301 and 302 redirects (but not 303
redirects), but the W3C recommends using 303 redirects for publishing RDF
vocabularies (https://www.w3.org/TR/swbp-vocab-pub/), which is what the Dublin
Core vocabularies use.
This sort of redirect handling worked previously, e.g. Jena 3.1.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-1263) Configure HTTP client to follow 303 redirects
[
https://issues.apache.org/jira/browse/JENA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Coburn updated JENA-1263:
---
Description:
When calling RDFDataMgr.read(Model model, String uri), the underlying HTTP
client does not appear to follow 303 redirects. For example:
{code:java}
Model m = createDefaultModel();
RDFDataMgr.read(m, "http://purl.org/dc/terms/";);
{code}
{code}
org.apache.jena.riot.RiotException: Failed to determine the content type:
(URI=http://purl.org/dc/terms/ : stream=text/html)
{code}
A work-around is to add a static block with a custom HTTP client like so:
{code:java}
static {
HttpOp.setDefaultHttpClient(
HttpClientBuilder.create().setRedirectStrategy(
new LaxRedirectStrategy()).build());
}
{code}
By default the Apache HTTP client follows 301 and 302 redirects (but not 303
redirects), but the W3C recommends using 303 redirects for publishing RDF
vocabularies (https://www.w3.org/TR/swbp-vocab-pub/), which is what the Dublin
Core vocabularies use.
This sort of redirect handling worked previously, e.g. Jena 3.1.0; it would be
convenient if the underlying HTTP client simply followed the 303 redirects.
was:
When calling RDFDataMgr.read(Model model, String uri), the underlying HTTP
client does not appear to follow 303 redirects. For example:
Model m = createDefaultModel();
RDFDataMgr.read(m, "http://purl.org/dc/terms/";);
org.apache.jena.riot.RiotException: Failed to determine the content type:
(URI=http://purl.org/dc/terms/ : stream=text/html)
A work-around is to add a static block with a custom HTTP client like so:
static {
HttpOp.setDefaultHttpClient(HttpClientBuilder.create().setRedirectStrategy(new
LaxRedirectStrategy()).build());
}
By default the Apache HTTP client follows 301 and 302 redirects (but not 303
redirects), but the W3C recommends using 303 redirects for publishing RDF
vocabularies (https://www.w3.org/TR/swbp-vocab-pub/), which is what the Dublin
Core vocabularies use.
This sort of redirect handling worked previously, e.g. Jena 3.1.0.
> Configure HTTP client to follow 303 redirects
> --
>
> Key: JENA-1263
> URL: https://issues.apache.org/jira/browse/JENA-1263
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Affects Versions: Jena 3.1.1
>Reporter: Aaron Coburn
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.2.0
>
>
> When calling RDFDataMgr.read(Model model, String uri), the underlying HTTP
> client does not appear to follow 303 redirects. For example:
> {code:java}
> Model m = createDefaultModel();
> RDFDataMgr.read(m, "http://purl.org/dc/terms/";);
> {code}
> {code}
> org.apache.jena.riot.RiotException: Failed to determine the content type:
> (URI=http://purl.org/dc/terms/ : stream=text/html)
> {code}
> A work-around is to add a static block with a custom HTTP client like so:
> {code:java}
> static {
> HttpOp.setDefaultHttpClient(
> HttpClientBuilder.create().setRedirectStrategy(
> new LaxRedirectStrategy()).build());
> }
> {code}
> By default the Apache HTTP client follows 301 and 302 redirects (but not 303
> redirects), but the W3C recommends using 303 redirects for publishing RDF
> vocabularies (https://www.w3.org/TR/swbp-vocab-pub/), which is what the
> Dublin Core vocabularies use.
> This sort of redirect handling worked previously, e.g. Jena 3.1.0; it would
> be convenient if the underlying HTTP client simply followed the 303 redirects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JENA-1378) RDFDataMgr does not perform conneg when reading remote RDF resources
Aaron Coburn created JENA-1378:
--
Summary: RDFDataMgr does not perform conneg when reading remote
RDF resources
Key: JENA-1378
URL: https://issues.apache.org/jira/browse/JENA-1378
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 3.4.0
Reporter: Aaron Coburn
In the past, I have been able to use RDFDataMgr.read(Graph, String) to fetch
vocabularies like so:
final Graph graph = Factory.createDefaultGraph();
RDFDataMgr.read(graph, "http://purl.org/dc/terms";);
This no longer works in 3.4.0. The error is:
org.apache.jena.riot.RiotException: Failed to determine the content type:
(URI=http://purl.org/dc/terms/ : stream=text/html)
The key thing about these remote resources is that they involve content
negotiation in order to get to the RDF serialization; otherwise an HTML page is
returned that cannot be parsed by RIOT.
Adding a Lang attribute to the read() function does not help.
This appears to be due to the RDFParser library not including an Accept header
in the HTTP request to the remote resource: https://git.io/v7sTV
Perhaps a good solution would be to provide a default accept header
("text/turtle, application/rdf+xml, application/ld+json") or, even better, that
accept header could be configurable by a client.
A work-around for me is to just use the HttpOp.execHttpGet function directly,
but it would be nice if this functioned as it once did.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-1378) RDFDataMgr does not perform conneg when reading remote RDF resources
[
https://issues.apache.org/jira/browse/JENA-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103203#comment-16103203
]
Aaron Coburn commented on JENA-1378:
[~andy.seaborne] thanks! The RDFParser class is new to me, and I hadn't noticed
the httpAccept method, which will work perfectly for my use. That said, the PR
mentioned above also looks great.
> RDFDataMgr does not perform conneg when reading remote RDF resources
>
>
> Key: JENA-1378
> URL: https://issues.apache.org/jira/browse/JENA-1378
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Aaron Coburn
>
> In the past, I have been able to use RDFDataMgr.read(Graph, String) to fetch
> vocabularies like so:
> final Graph graph = Factory.createDefaultGraph();
> RDFDataMgr.read(graph, "http://purl.org/dc/terms";);
> This no longer works in 3.4.0. The error is:
> org.apache.jena.riot.RiotException: Failed to determine the content
> type: (URI=http://purl.org/dc/terms/ : stream=text/html)
> The key thing about these remote resources is that they involve content
> negotiation in order to get to the RDF serialization; otherwise an HTML page
> is returned that cannot be parsed by RIOT.
> Adding a Lang attribute to the read() function does not help.
> This appears to be due to the RDFParser library not including an Accept
> header in the HTTP request to the remote resource: https://git.io/v7sTV
> Perhaps a good solution would be to provide a default accept header
> ("text/turtle, application/rdf+xml, application/ld+json") or, even better,
> that accept header could be configurable by a client.
> A work-around for me is to just use the HttpOp.execHttpGet function directly,
> but it would be nice if this functioned as it once did.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JENA-1508) Update OSGi provisioning features
Aaron Coburn created JENA-1508: -- Summary: Update OSGi provisioning features Key: JENA-1508 URL: https://issues.apache.org/jira/browse/JENA-1508 Project: Apache Jena Issue Type: Improvement Components: OSGi Affects Versions: Jena 3.6.0 Reporter: Aaron Coburn Fix For: Jena 3.7.0 Deploying Jena in an OSGi container (such as Karaf) using the provided features.xml artifact fails because of a dependency on the com.google.errorprone.annotations.concurrent package (this comes as an optional dependency of guava: it is not directly used in the Jena codebase). By indicating that this package is optional, the error goes away. Secondarily, the 3.7.0 SNAPSHOT contains a new dependency on commons-codec, which should be added to the features.xml file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1508) Update OSGi provisioning features
[ https://issues.apache.org/jira/browse/JENA-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402394#comment-16402394 ] Aaron Coburn commented on JENA-1508: One item to note about this is that, in the Karaf 4.2.0.M2 release, Xerces is no longer included by default. It is quite useful that the current features.xml file provides a xerces feature, but I wonder at what point that feature should be installed as part of the jena feature. For reference: https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi-features/src/main/resources/features.xml#L25 > Update OSGi provisioning features > - > > Key: JENA-1508 > URL: https://issues.apache.org/jira/browse/JENA-1508 > Project: Apache Jena > Issue Type: Improvement > Components: OSGi >Affects Versions: Jena 3.6.0 >Reporter: Aaron Coburn >Priority: Minor > Fix For: Jena 3.7.0 > > > Deploying Jena in an OSGi container (such as Karaf) using the provided > features.xml artifact fails because of a dependency on the > com.google.errorprone.annotations.concurrent package (this comes as an > optional dependency of guava: it is not directly used in the Jena codebase). > By indicating that this package is optional, the error goes away. > Secondarily, the 3.7.0 SNAPSHOT contains a new dependency on commons-codec, > which should be added to the features.xml file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1538) Include TDB2 in jena-osgi module
Aaron Coburn created JENA-1538: -- Summary: Include TDB2 in jena-osgi module Key: JENA-1538 URL: https://issues.apache.org/jira/browse/JENA-1538 Project: Apache Jena Issue Type: Improvement Components: TDB2 Affects Versions: Jena 3.7.0 Reporter: Aaron Coburn Fix For: Jena 3.8.0 The jena-tdb2 packages are not included in the jena-osgi module. Should they be? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1557) Update OSGi imports for 3.8 release
Aaron Coburn created JENA-1557: -- Summary: Update OSGi imports for 3.8 release Key: JENA-1557 URL: https://issues.apache.org/jira/browse/JENA-1557 Project: Apache Jena Issue Type: Improvement Components: OSGi Environment: Karaf 4.2.0 Reporter: Aaron Coburn Fix For: Jena 3.8.0 The updates to various dependencies make it hard to install Jena in an OSGi container. It would be good to update the features.xml file and add some exclusions to the jena-osgi import declaration. In particular: jsonld-java now depends on Guava/24.1-jre jena now depends on commons-compress jena-shaded-guava tries to import too many packages (e.g. org.checkerframework) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1599) Upgrade to jsonld-java version 0.12.1
Aaron Coburn created JENA-1599: -- Summary: Upgrade to jsonld-java version 0.12.1 Key: JENA-1599 URL: https://issues.apache.org/jira/browse/JENA-1599 Project: Apache Jena Issue Type: Improvement Affects Versions: Jena 3.8.0 Reporter: Aaron Coburn Assignee: Aaron Coburn Fix For: Jena 3.9.0 There is a new patch release of jsonld-java. Upgrading to 0.12.1 will also make it possible for the OSGi features.xml file to not have to explicitly import an older version of Guava (as was necessary for 0.12.0) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1599) Upgrade to jsonld-java version 0.12.1
[ https://issues.apache.org/jira/browse/JENA-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn resolved JENA-1599. Resolution: Fixed > Upgrade to jsonld-java version 0.12.1 > - > > Key: JENA-1599 > URL: https://issues.apache.org/jira/browse/JENA-1599 > Project: Apache Jena > Issue Type: Improvement >Affects Versions: Jena 3.8.0 > Reporter: Aaron Coburn >Assignee: Aaron Coburn >Priority: Minor > Fix For: Jena 3.9.0 > > > There is a new patch release of jsonld-java. Upgrading to 0.12.1 will also > make it possible for the OSGi features.xml file to not have to explicitly > import an older version of Guava (as was necessary for 0.12.0) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1635) Invalid Automatic-Module-Names in fuseki2 modules
Aaron Coburn created JENA-1635: -- Summary: Invalid Automatic-Module-Names in fuseki2 modules Key: JENA-1635 URL: https://issues.apache.org/jira/browse/JENA-1635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Jena 3.9.0 Reporter: Aaron Coburn Fix For: Jena 3.10.0 The maven configuration for some of the fuseki2 modules produces syntactically invalid Automatic-Module-Name values (dashes are not permitted). For instance, org.apache.jena.jena-fuseki-main would need to be changed to org.apache.jena.fuseki2.main -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JENA-1635) Invalid Automatic-Module-Names in fuseki2 modules
[ https://issues.apache.org/jira/browse/JENA-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn reassigned JENA-1635: -- Assignee: Aaron Coburn > Invalid Automatic-Module-Names in fuseki2 modules > - > > Key: JENA-1635 > URL: https://issues.apache.org/jira/browse/JENA-1635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.9.0 >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Major > Fix For: Jena 3.10.0 > > > The maven configuration for some of the fuseki2 modules produces > syntactically invalid Automatic-Module-Name values (dashes are not permitted). > For instance, org.apache.jena.jena-fuseki-main would need to be changed to > org.apache.jena.fuseki2.main -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1653) Duplicate Automatic-Module-Name values
Aaron Coburn created JENA-1653: -- Summary: Duplicate Automatic-Module-Name values Key: JENA-1653 URL: https://issues.apache.org/jira/browse/JENA-1653 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 3.9.0 Reporter: Aaron Coburn Fix For: Jena 3.10.0 Many of the artifacts that are part of jena-db contain duplicate values for the Automatic-Module-Name manifest headers. The problematic modules are: * jena-dboe-base * jena-dboe-index * jena-dboe-index-test * jena-dboe-transation * jena-dboe-trans-data All of these contain the same value for Automatic-Module-Name: org.apache.jena.dboe Instead, they should each advertise a unique module name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825205#comment-16825205
]
Aaron Coburn commented on JENA-1704:
What I've done with some of my own projects is to add the sonar analysis to an
\{after_success} section in the travis configuration. That way, it can't ever
fail a build; sometimes sonarcloud might be down, etc. I have also found that
it is best to run the \{sonar:sonar} analysis only for one particular
environment – for example, run the analysis on openjdk8 but not on oraclejdk8
(it doesn't matter so much which one, just pick one environment).
> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis
> must not annoy anyone working on the codebase or make development less
> pleasant, so it must be done carefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1741) Invalid Automatic-Module-Name values
Aaron Coburn created JENA-1741: -- Summary: Invalid Automatic-Module-Name values Key: JENA-1741 URL: https://issues.apache.org/jira/browse/JENA-1741 Project: Apache Jena Issue Type: Improvement Components: Spatial Affects Versions: Jena 3.12.0 Reporter: Aaron Coburn Assignee: Aaron Coburn Fix For: Jena 3.13.0 Similar to JENA-1635, the Automatic-Module-Name metadata for the two new geosparql modules contains invalid names. Hyphens are not allowed here. The fix is to rename org.apache.jena.jena-fuseki-geosparql to org.apache.jena.fuseki.geosparql and org.apache.jena.jena-geosparql to org.apache.jena.geosparql -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (JENA-1742) Fix OSGi imports
Aaron Coburn created JENA-1742: -- Summary: Fix OSGi imports Key: JENA-1742 URL: https://issues.apache.org/jira/browse/JENA-1742 Project: Apache Jena Issue Type: Improvement Components: OSGi Affects Versions: Jena 3.12.0 Reporter: Aaron Coburn Fix For: Jena 3.13.0 The Jena 3.12.0 OSGi artifact introduces two new, unused package imports: com.google.appengine.api and com.google.apphosting.api It is a little unclear to me where these are pulled from, but they certainly are not used anywhere in the runtime code. In all likelihood, they are an optional transitive dependency, but they make it harder to run Jena in an OSGi context. I would suggest adding an explicit exclusion for these packages in the OSGi module. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (JENA-1742) Fix OSGi imports
[ https://issues.apache.org/jira/browse/JENA-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn resolved JENA-1742. Assignee: Aaron Coburn Resolution: Fixed > Fix OSGi imports > > > Key: JENA-1742 > URL: https://issues.apache.org/jira/browse/JENA-1742 > Project: Apache Jena > Issue Type: Improvement > Components: OSGi >Affects Versions: Jena 3.12.0 >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Major > Fix For: Jena 3.13.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The Jena 3.12.0 OSGi artifact introduces two new, unused package imports: > com.google.appengine.api and com.google.apphosting.api > It is a little unclear to me where these are pulled from, but they certainly > are not used anywhere in the runtime code. In all likelihood, they are an > optional transitive dependency, but they make it harder to run Jena in an > OSGi context. > I would suggest adding an explicit exclusion for these packages in the OSGi > module. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (JENA-1741) Invalid Automatic-Module-Name values
[ https://issues.apache.org/jira/browse/JENA-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn resolved JENA-1741. Resolution: Fixed > Invalid Automatic-Module-Name values > > > Key: JENA-1741 > URL: https://issues.apache.org/jira/browse/JENA-1741 > Project: Apache Jena > Issue Type: Improvement > Components: Spatial >Affects Versions: Jena 3.12.0 >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Major > Fix For: Jena 3.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Similar to JENA-1635, the Automatic-Module-Name metadata for the two new > geosparql modules contains invalid names. Hyphens are not allowed here. > The fix is to rename > org.apache.jena.jena-fuseki-geosparql to org.apache.jena.fuseki.geosparql > and > org.apache.jena.jena-geosparql to org.apache.jena.geosparql > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (JENA-1764) Fix missing and duplicate Automatic-Module-Name metadata
Aaron Coburn created JENA-1764: -- Summary: Fix missing and duplicate Automatic-Module-Name metadata Key: JENA-1764 URL: https://issues.apache.org/jira/browse/JENA-1764 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 3.12.0 Environment: Using Jena on Java11 when Jena artifacts are on the module path (rather than the class path) Reporter: Aaron Coburn Assignee: Aaron Coburn The Java9+ module system makes use of the MANIFEST header: Automatic-Module-Name. This header is optional, but if present it needs to be globally unique and must follow certain formatting rules (e.g. no hyphens). The Automatic-Module-Name header in the jena-dboe-storage artifact is empty (not missing), which is invalid. In addition, the various jena-elephas-* and jena-jdbc-* artifacts contain duplicate module name declarations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1830) travis.yml
[
https://issues.apache.org/jira/browse/JENA-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023869#comment-17023869
]
Aaron Coburn commented on JENA-1830:
+1 for testing only LTS versions.
If the test failures are intermittent and/or inconsistent on TravisCI, it is
also possible to add {{travis_retry}} to the build command, e.g.:
script: travis_retry mvn -B clean install
That would cause the tests to run up to three times. If any one passes, then
the job succeeds.
It may also be reasonable to allow the non-LTS (latest) JDK version to fail.
At present, that would be version 13; Java 14 (also non-LTS) will be released
in March 2020.
> travis.yml
> --
>
> Key: JENA-1830
> URL: https://issues.apache.org/jira/browse/JENA-1830
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>
> Jena has several JVM versions in the Travis setup. In addition, the Jenkins
> server has full build and test runs.
> I use Travis (free option) to verify development changes but the build
> process is not perfect. A complete cycle is 5 travis builds and if any one
> fails, the job is flagged in error. The errors are not Jena related - they
> are build environment issues reflected as maven build problems.
> In the last 50 jobs without development failures, I got 24 green, 22 failed
> one or two jobs and 4 build system fails. So I get 40% false reports of code
> failures.
> The individual fails were distributed as:
> Java8 : 3
> Java9 : 3
> Java10: 4
> Java11: 2
> Java12: 10
> The problem is that with 5 fairly reliable jobs, the probablity of a "failed"
> build is increased. This is semi-interactive feedback, unlike Jenkins which
> is a daily set of builds.
> I propose having LTS (8,11, and soon 14).
> Jenkins will provide the more complete testing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-1833) Add jena-commonsrdf to jena-osgi
[ https://issues.apache.org/jira/browse/JENA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn resolved JENA-1833. Assignee: Aaron Coburn Resolution: Fixed > Add jena-commonsrdf to jena-osgi > > > Key: JENA-1833 > URL: https://issues.apache.org/jira/browse/JENA-1833 > Project: Apache Jena > Issue Type: Task > Components: OSGi >Reporter: Andy Seaborne >Assignee: Aaron Coburn >Priority: Major > Fix For: Jena 3.15.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Follow-on from JENA-1828. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JENA-1888) Exclude log4j2 from OSGi bundle
Aaron Coburn created JENA-1888: -- Summary: Exclude log4j2 from OSGi bundle Key: JENA-1888 URL: https://issues.apache.org/jira/browse/JENA-1888 Project: Apache Jena Issue Type: Improvement Components: OSGi Environment: OSGi (Karaf 4.2.7+) Reporter: Aaron Coburn Assignee: Aaron Coburn Fix For: Jena 3.15.0 The jena osgi bundle has a dependency on log4j2, but this should be excluded in the bundle metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JENA-1888) Mark log4j2 optional in OSGi bundle
[ https://issues.apache.org/jira/browse/JENA-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn updated JENA-1888: --- Description: The jena osgi bundle has a dependency on log4j2, but this should be marked as optional in the bundle metadata. (was: The jena osgi bundle has a dependency on log4j2, but this should be excluded in the bundle metadata.) > Mark log4j2 optional in OSGi bundle > --- > > Key: JENA-1888 > URL: https://issues.apache.org/jira/browse/JENA-1888 > Project: Apache Jena > Issue Type: Improvement > Components: OSGi > Environment: OSGi (Karaf 4.2.7+) >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Minor > Fix For: Jena 3.15.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The jena osgi bundle has a dependency on log4j2, but this should be marked as > optional in the bundle metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JENA-1888) Mark log4j2 optional in OSGi bundle
[ https://issues.apache.org/jira/browse/JENA-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn resolved JENA-1888. Resolution: Fixed > Mark log4j2 optional in OSGi bundle > --- > > Key: JENA-1888 > URL: https://issues.apache.org/jira/browse/JENA-1888 > Project: Apache Jena > Issue Type: Improvement > Components: OSGi > Environment: OSGi (Karaf 4.2.7+) >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Minor > Fix For: Jena 3.15.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The jena osgi bundle has a dependency on log4j2, but this should be excluded > in the bundle metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JENA-1888) Mark log4j2 optional in OSGi bundle
[ https://issues.apache.org/jira/browse/JENA-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn updated JENA-1888: --- Summary: Mark log4j2 optional in OSGi bundle (was: Exclude log4j2 from OSGi bundle) > Mark log4j2 optional in OSGi bundle > --- > > Key: JENA-1888 > URL: https://issues.apache.org/jira/browse/JENA-1888 > Project: Apache Jena > Issue Type: Improvement > Components: OSGi > Environment: OSGi (Karaf 4.2.7+) >Reporter: Aaron Coburn > Assignee: Aaron Coburn >Priority: Minor > Fix For: Jena 3.15.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The jena osgi bundle has a dependency on log4j2, but this should be excluded > in the bundle metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
