[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] [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-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-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-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] [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)
[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] [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] [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] [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] [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] [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] [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] [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] [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] [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-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] [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-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] [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-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] [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-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] [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-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-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-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] [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-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)
