[jira] [Created] (JENA-1998) Provide SHACL imports processing.
Andy Seaborne created JENA-1998:
---
Summary: Provide SHACL imports processing.
Key: JENA-1998
URL: https://issues.apache.org/jira/browse/JENA-1998
Project: Apache Jena
Issue Type: Improvement
Components: SHACL
Affects Versions: Jena 3.16.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Fix For: Jena 3.17.0
SHACL has an import mechanism using {{owl:imports}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-824) Concurrent usage of query causes NPE
[ https://issues.apache.org/jira/browse/JENA-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-824. Fix Version/s: Jena 3.15.0 Assignee: Andy Seaborne Resolution: Fixed Fixed by JENA-1861. > Concurrent usage of query causes NPE > > > Key: JENA-824 > URL: https://issues.apache.org/jira/browse/JENA-824 > Project: Apache Jena > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.15.0 > > > Callin gQueryFactory.parse and then handling the Query off to multiple > threads can/will cause the error show in the stacktrace. > As long as setResultVars is called on the Query before handing off to > threads, it seems to be safe. > Pull request is coming on this. > java.lang.NullPointerException > at com.hp.hpl.jena.sparql.core.Var.varNames(Var.java:193) > at com.hp.hpl.jena.query.Query.getResultVars(Query.java:369) > at > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.asResultSet(QueryExecutionBase.java:470) > at > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:533) > at com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JENA-824) Concurrent usage of query causes NPE
[ https://issues.apache.org/jira/browse/JENA-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-824. -- > Concurrent usage of query causes NPE > > > Key: JENA-824 > URL: https://issues.apache.org/jira/browse/JENA-824 > Project: Apache Jena > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.15.0 > > > Callin gQueryFactory.parse and then handling the Query off to multiple > threads can/will cause the error show in the stacktrace. > As long as setResultVars is called on the Query before handing off to > threads, it seems to be safe. > Pull request is coming on this. > java.lang.NullPointerException > at com.hp.hpl.jena.sparql.core.Var.varNames(Var.java:193) > at com.hp.hpl.jena.query.Query.getResultVars(Query.java:369) > at > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.asResultSet(QueryExecutionBase.java:470) > at > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:533) > at com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston closed JENA-1996.
---
Fix Version/s: Jena 3.17.0
Resolution: Fixed
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston reassigned JENA-1996:
---
Assignee: Greg Albiston
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232336#comment-17232336
]
Greg Albiston commented on JENA-1996:
-
Test has been fixed and is now in `master`.
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
jena-core: status of turtle for tests.
JENA-1997 I found an experiment that removed the jena-core Turtle writer. jena-core need Turtle parsing for it's test suite. The tests don't use the very old Turtle/N3 subsystem it for writing. This old Turtle parser/writer isn't compliant with the current Turtle spec. At the same time, there are several RDFWriterF (factory) methods that don't make sense when RIOT i sused. This changes the mode Interface to remove deprecated functionality and which didn't actually do anything anyway when RIOT was in-use. The only people who might be affected are those using jena-core without jena-arq and also who upgrade Jena. Claude - there are jena-permission changes to match - they are check+pass-thru's. Andy
Re: dependabot results
On 12/11/2020 23:56, Aaron Coburn wrote: Thanks, that was a bit of work from a question about just one dependency, :-) BTW was there a particular fix in HttpClient 4.5.13 that you wanted? 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
[jira] [Commented] (JENA-1988) Separating B+ tree into different Node representations.
[ https://issues.apache.org/jira/browse/JENA-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232252#comment-17232252 ] Martin Pekár commented on JENA-1988: No, I don't have any cost figures. So, would it in theory be possible to let the NodeTableCache have four instances of NodeTableNative instead, one for node type? > Separating B+ tree into different Node representations. > --- > > Key: JENA-1988 > URL: https://issues.apache.org/jira/browse/JENA-1988 > Project: Apache Jena > Issue Type: Question > Components: TDB >Affects Versions: Jena 3.16.0 >Reporter: Martin Pekár >Priority: Major > Labels: features, newbie, performance, test > Fix For: Jena 3.16.0 > > Attachments: NodeTableNative.java > > > In a project to optimize the indexing, I am trying to have 4 indexes, one for > each Node type (variable, literal, URI and blank). To implement this, I added > 4 copies of the _nodeHashToId_ Index instance in the _NodeTableNative_ class. > Then, for every operation on the _nodeHashToId_, for example using > _containsNode()_ in the NodeTableNative class, I first check the type of Node > given as parameter and then check for existence in the appropriate > _nodeHashToId_ copy. > Now, for some reason I get a NullPointerException when running the tests. > Many of these exceptions appear in the _BufferChannelFile_ class in the > _size()_ method because the call to _file.channel()_ return null. > My question is then, is _NodeTableNative___ even the right place to implement > this optimization, and second, if it is the right place to implement, can you > help me understand why this exception is thrown? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JENA-1997) Remove old Turtle/N3 writer (jena-core)
[ https://issues.apache.org/jira/browse/JENA-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1997: Description: jena-core contains an old Turtle/N3 writer. (The N3 is for data only - not N3 nested graphs). Jena-core only needs Turtle/N3 because there are tests written using Turtle. The jena-core parser and writer are not up-to-date with the Turtle W3C Recommendation and are replaced in normal use by the Turtle support in RIOT. While the reader is needed for test data, the writer is not used. It would only be used by applications depending on jena-core without the rest of apache-jena-libs (specifically, jena-arq for RIOT). If RIOT is present, then the writer will have been rewired to be the correct one. The overall result is that jena-core has RDF/XML, an N-Triples reader and a basicTurtle parser. jena-core is not intended for standalone use. We have has apache-jena-libs fora long time now. was: jena-core contains an old Turtle/N3 writer. (The N3 is for data only - not N3 nested graphs). Jena-core only needs Turtle/N3 because there are tests written using Turtle. The jena-core parser and writer are not up-to-date with the Turtle W3C Recommendation and are replaced in normal use by the Turtle support in RIOT. While the reader is needed for test data, the writer is not used. Proposal for migration: * Remove the access to the N3 data writer * When it is clear it is not used, delete it. It would only be used by applications depending on jena-core without the rest of apache-jena-libs (specifically, jena-arq for RIOT). If RIOT is present, then the writer will have been rewired to be the correct one. > Remove old Turtle/N3 writer (jena-core) > --- > > Key: JENA-1997 > URL: https://issues.apache.org/jira/browse/JENA-1997 > Project: Apache Jena > Issue Type: Improvement > Components: Core >Affects Versions: Jena 3.16.0 >Reporter: Andy Seaborne >Priority: Major > > jena-core contains an old Turtle/N3 writer. (The N3 is for data only - not N3 > nested graphs). > Jena-core only needs Turtle/N3 because there are tests written using Turtle. > The jena-core parser and writer are not up-to-date with the Turtle W3C > Recommendation and are replaced in normal use by the Turtle support in RIOT. > While the reader is needed for test data, the writer is not used. > It would only be used by applications depending on jena-core without the rest > of apache-jena-libs (specifically, jena-arq for RIOT). If RIOT is present, > then the writer will have been rewired to be the correct one. > The overall result is that jena-core has RDF/XML, an N-Triples reader and a > basicTurtle parser. > jena-core is not intended for standalone use. We have has apache-jena-libs > fora long time now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JENA-1997) Remove old Turtle/N3 writer (jena-core)
Andy Seaborne created JENA-1997: --- Summary: Remove old Turtle/N3 writer (jena-core) Key: JENA-1997 URL: https://issues.apache.org/jira/browse/JENA-1997 Project: Apache Jena Issue Type: Improvement Components: Core Affects Versions: Jena 3.16.0 Reporter: Andy Seaborne jena-core contains an old Turtle/N3 writer. (The N3 is for data only - not N3 nested graphs). Jena-core only needs Turtle/N3 because there are tests written using Turtle. The jena-core parser and writer are not up-to-date with the Turtle W3C Recommendation and are replaced in normal use by the Turtle support in RIOT. While the reader is needed for test data, the writer is not used. Proposal for migration: * Remove the access to the N3 data writer * When it is clear it is not used, delete it. It would only be used by applications depending on jena-core without the rest of apache-jena-libs (specifically, jena-arq for RIOT). If RIOT is present, then the writer will have been rewired to be the correct one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JENA-909) Create Docker launcher for Fuseki
[ https://issues.apache.org/jira/browse/JENA-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne reassigned JENA-909: -- Assignee: Andy Seaborne > Create Docker launcher for Fuseki > - > > Key: JENA-909 > URL: https://issues.apache.org/jira/browse/JENA-909 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.17.0 > > Attachments: Dockerfile.0, image-2019-10-02-22-24-12-723.png, > log4j.properties > > > Provide a Docker launcher and setup documentation for Fuseki2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JENA-1939) getUpdateCount() in the JDBC driver returns incorrect value - it looks like there are always more results (infinite loop)
[
https://issues.apache.org/jira/browse/JENA-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne reassigned JENA-1939:
---
Assignee: Rob Vesse
> getUpdateCount() in the JDBC driver returns incorrect value - it looks like
> there are always more results (infinite loop)
> -
>
> Key: JENA-1939
> URL: https://issues.apache.org/jira/browse/JENA-1939
> Project: Apache Jena
> Issue Type: Bug
> Components: JDBC
>Reporter: František Kučera
>Assignee: Rob Vesse
>Priority: Major
> Fix For: Jena 3.17.0
>
> Attachments: jena-jdbc-updateCount-patch-01.diff
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The method {{JenaStatement.getUpdateCount()}} returns 0. But
> [java.sql.Statement|https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#getUpdateCount--]
> documentation says:
> bq. Returns: the current result as an update count; -1 if the current result
> is a ResultSet object or there are no more results
> Returning correct value is important because a single statement may have
> multiple result sets and cause mutiple updates (not only multiple updated
> records, but multiple sets of updated records).
> Applications (e.g. [SQL-DK|http://sql-dk.globalcode.info/]) iterate over
> these multiple results and need to know when finish. The
> [getMoreResults()|https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#getMoreResults--]
> documentation says:
> bq. There are no more results when the following is true:
> {{((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))}}
> But if 0 is returned, the application enters infinite loop.
> I think that [change in my
> branch|https://git-zaloha.frantovo.cz/gitbox.apache.org/repos/asf/jena.git/log/?h=JENA-1939_updateCount]
> could resolve this issue (also attached as a patch).
> P.S. Is there a way to return actual count of updated records?
> ({{UpdateProcessor.execute()}} returns void).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-1994) PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in typed literals
[ https://issues.apache.org/jira/browse/JENA-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1994. - Fix Version/s: Jena 3.17.0 Assignee: Andy Seaborne Resolution: Fixed > PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in > typed literals > > > Key: JENA-1994 > URL: https://issues.apache.org/jira/browse/JENA-1994 > Project: Apache Jena > Issue Type: Bug > Components: Jena >Reporter: Jan Rosecky >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.17.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Prefixes used in typed literals are not reflected in computed prefix mapping > used in given the graph, as calculated by > PrefixMappingUtils.calcInUsePrefixMapping(). > > Not really sure if this is a bug or a feature request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1994) PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in typed literals
[ https://issues.apache.org/jira/browse/JENA-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232223#comment-17232223 ] ASF subversion and git services commented on JENA-1994: --- Commit b85e31d0526584d6f64662670dce8379c40a28d8 in jena's branch refs/heads/master from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=b85e31d ] JENA-1994: Look in datatype URI (#864) JENA-1994: Look in datatype URI > PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in > typed literals > > > Key: JENA-1994 > URL: https://issues.apache.org/jira/browse/JENA-1994 > Project: Apache Jena > Issue Type: Bug > Components: Jena >Reporter: Jan Rosecky >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Prefixes used in typed literals are not reflected in computed prefix mapping > used in given the graph, as calculated by > PrefixMappingUtils.calcInUsePrefixMapping(). > > Not really sure if this is a bug or a feature request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1994) PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in typed literals
[ https://issues.apache.org/jira/browse/JENA-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1723#comment-1723 ] ASF subversion and git services commented on JENA-1994: --- Commit b85e31d0526584d6f64662670dce8379c40a28d8 in jena's branch refs/heads/master from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=b85e31d ] JENA-1994: Look in datatype URI (#864) JENA-1994: Look in datatype URI > PrefixMappingUtils.calcInUsePrefixMapping() does not reflect prefixes used in > typed literals > > > Key: JENA-1994 > URL: https://issues.apache.org/jira/browse/JENA-1994 > Project: Apache Jena > Issue Type: Bug > Components: Jena >Reporter: Jan Rosecky >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Prefixes used in typed literals are not reflected in computed prefix mapping > used in given the graph, as calculated by > PrefixMappingUtils.calcInUsePrefixMapping(). > > Not really sure if this is a bug or a feature request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
