[jira] [Resolved] (JENA-1619) TransactionException for large query results
[ https://issues.apache.org/jira/browse/JENA-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1619. - Resolution: Fixed Assignee: Andy Seaborne Fix Version/s: Jena 3.10.0 > TransactionException for large query results > > > Key: JENA-1619 > URL: https://issues.apache.org/jira/browse/JENA-1619 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.9.0 > Environment: MacOS 10.14 > Java 1.8.0_161 (Oracle) >Reporter: Damien Obrist >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.10.0 > > Attachments: jena-transaction-exception-master.zip > > > When querying a TDB2 dataset, I'm observing a suspicious > {{TransactionException}}, even though the query results have been copied so > they can be used outside of a transaction. The exception only seems to occur > when there are many results. > h3. Reproduction steps > * Sample dataset containing 1'000'000 triples > * Query all triples: > {code:java} > SELECT * WHERE { ?s ?p ?o . }{code} > * Copy query results for use outside of transaction: > {code:java} > ResultSetFactory.copyResults(queryExecution.execSelect());{code} > * Get any variable of the first result > All variables are {{null}} and the log shows the following exception: > {noformat} > org.apache.jena.dboe.transaction.txn.TransactionException: Not in a > transaction > at > org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417) > at > org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182) > at > org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71) > at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) > at > org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637) > at > org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213) > at org.apache.thrift.TUnion.read(TUnion.java:138) > at > org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108) > at > org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66) > at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126) > at > org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104) > at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57) > at > org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33) > at TransactionException.main(TransactionException.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) > at java.lang.Thread.run(Thread.java:748) > {noformat} > I have created a minimal example available on > [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached > to this issue. > h3. Findings > * The exception doesn't occur for smaller query results > * This seems to be a regression as it works as expected with Jena 3.8.0 > * Using {{git bisect}} I have identified the commit where this starts to > happen: > [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1619) TransactionException for large query results
[ https://issues.apache.org/jira/browse/JENA-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664014#comment-16664014 ] ASF GitHub Bot commented on JENA-1619: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/482 > TransactionException for large query results > > > Key: JENA-1619 > URL: https://issues.apache.org/jira/browse/JENA-1619 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.9.0 > Environment: MacOS 10.14 > Java 1.8.0_161 (Oracle) >Reporter: Damien Obrist >Priority: Major > Attachments: jena-transaction-exception-master.zip > > > When querying a TDB2 dataset, I'm observing a suspicious > {{TransactionException}}, even though the query results have been copied so > they can be used outside of a transaction. The exception only seems to occur > when there are many results. > h3. Reproduction steps > * Sample dataset containing 1'000'000 triples > * Query all triples: > {code:java} > SELECT * WHERE { ?s ?p ?o . }{code} > * Copy query results for use outside of transaction: > {code:java} > ResultSetFactory.copyResults(queryExecution.execSelect());{code} > * Get any variable of the first result > All variables are {{null}} and the log shows the following exception: > {noformat} > org.apache.jena.dboe.transaction.txn.TransactionException: Not in a > transaction > at > org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417) > at > org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182) > at > org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71) > at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) > at > org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637) > at > org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213) > at org.apache.thrift.TUnion.read(TUnion.java:138) > at > org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108) > at > org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66) > at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126) > at > org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104) > at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57) > at > org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33) > at TransactionException.main(TransactionException.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) > at java.lang.Thread.run(Thread.java:748) > {noformat} > I have created a minimal example available on > [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached > to this issue. > h3. Findings > * The exception doesn't occur for smaller query results > * This seems to be a regression as it works as expected with Jena 3.8.0 > * Using {{git bisect}} I have identified the commit where this starts to > happen: > [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1619) TransactionException for large query results
[ https://issues.apache.org/jira/browse/JENA-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664012#comment-16664012 ] ASF subversion and git services commented on JENA-1619: --- Commit c3027d69ac87763113322876816fb6292ef6cd6a in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c3027d6 ] JENA-1619: Merge commit 'refs/pull/482/head' of https://github.com/apache/jena This closes #482. > TransactionException for large query results > > > Key: JENA-1619 > URL: https://issues.apache.org/jira/browse/JENA-1619 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.9.0 > Environment: MacOS 10.14 > Java 1.8.0_161 (Oracle) >Reporter: Damien Obrist >Priority: Major > Attachments: jena-transaction-exception-master.zip > > > When querying a TDB2 dataset, I'm observing a suspicious > {{TransactionException}}, even though the query results have been copied so > they can be used outside of a transaction. The exception only seems to occur > when there are many results. > h3. Reproduction steps > * Sample dataset containing 1'000'000 triples > * Query all triples: > {code:java} > SELECT * WHERE { ?s ?p ?o . }{code} > * Copy query results for use outside of transaction: > {code:java} > ResultSetFactory.copyResults(queryExecution.execSelect());{code} > * Get any variable of the first result > All variables are {{null}} and the log shows the following exception: > {noformat} > org.apache.jena.dboe.transaction.txn.TransactionException: Not in a > transaction > at > org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417) > at > org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182) > at > org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71) > at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) > at > org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637) > at > org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213) > at org.apache.thrift.TUnion.read(TUnion.java:138) > at > org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108) > at > org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66) > at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126) > at > org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104) > at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57) > at > org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33) > at TransactionException.main(TransactionException.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) > at java.lang.Thread.run(Thread.java:748) > {noformat} > I have created a minimal example available on > [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached > to this issue. > h3. Findings > * The exception doesn't occur for smaller query results > * This seems to be a regression as it works as expected with Jena 3.8.0 > * Using {{git bisect}} I have identified the commit where this starts to > happen: > [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1619) TransactionException for large query results
[ https://issues.apache.org/jira/browse/JENA-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664010#comment-16664010 ] ASF subversion and git services commented on JENA-1619: --- Commit cd75e6c1597db5da1adf2eb3decd5bd59877b266 in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=cd75e6c ] JENA-1619: Completely detach a binding by doing a copy. > TransactionException for large query results > > > Key: JENA-1619 > URL: https://issues.apache.org/jira/browse/JENA-1619 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.9.0 > Environment: MacOS 10.14 > Java 1.8.0_161 (Oracle) >Reporter: Damien Obrist >Priority: Major > Attachments: jena-transaction-exception-master.zip > > > When querying a TDB2 dataset, I'm observing a suspicious > {{TransactionException}}, even though the query results have been copied so > they can be used outside of a transaction. The exception only seems to occur > when there are many results. > h3. Reproduction steps > * Sample dataset containing 1'000'000 triples > * Query all triples: > {code:java} > SELECT * WHERE { ?s ?p ?o . }{code} > * Copy query results for use outside of transaction: > {code:java} > ResultSetFactory.copyResults(queryExecution.execSelect());{code} > * Get any variable of the first result > All variables are {{null}} and the log shows the following exception: > {noformat} > org.apache.jena.dboe.transaction.txn.TransactionException: Not in a > transaction > at > org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417) > at > org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182) > at > org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71) > at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) > at > org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637) > at > org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213) > at org.apache.thrift.TUnion.read(TUnion.java:138) > at > org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108) > at > org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66) > at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126) > at > org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104) > at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57) > at > org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33) > at TransactionException.main(TransactionException.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) > at java.lang.Thread.run(Thread.java:748) > {noformat} > I have created a minimal example available on > [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached > to this issue. > h3. Findings > * The exception doesn't occur for smaller query results > * This seems to be a regression as it works as expected with Jena 3.8.0 > * Using {{git bisect}} I have identified the commit where this starts to > happen: > [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #482: JENA-1619: Completely detach results by copying a bi...
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/482 ---
[jira] [Commented] (JENA-1619) TransactionException for large query results
[ https://issues.apache.org/jira/browse/JENA-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664011#comment-16664011 ] ASF subversion and git services commented on JENA-1619: --- Commit c89ed1238bcee69918e7aeedaf52637c66ff315c in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c89ed12 ] JENA-1619: Don't materialize bindings. No need to materialize. Bindings aren't safe outside a transaction anyway. > TransactionException for large query results > > > Key: JENA-1619 > URL: https://issues.apache.org/jira/browse/JENA-1619 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.9.0 > Environment: MacOS 10.14 > Java 1.8.0_161 (Oracle) >Reporter: Damien Obrist >Priority: Major > Attachments: jena-transaction-exception-master.zip > > > When querying a TDB2 dataset, I'm observing a suspicious > {{TransactionException}}, even though the query results have been copied so > they can be used outside of a transaction. The exception only seems to occur > when there are many results. > h3. Reproduction steps > * Sample dataset containing 1'000'000 triples > * Query all triples: > {code:java} > SELECT * WHERE { ?s ?p ?o . }{code} > * Copy query results for use outside of transaction: > {code:java} > ResultSetFactory.copyResults(queryExecution.execSelect());{code} > * Get any variable of the first result > All variables are {{null}} and the log shows the following exception: > {noformat} > org.apache.jena.dboe.transaction.txn.TransactionException: Not in a > transaction > at > org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417) > at > org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182) > at > org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71) > at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) > at > org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637) > at > org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222) > at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213) > at org.apache.thrift.TUnion.read(TUnion.java:138) > at > org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103) > at > org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197) > at > org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108) > at > org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52) > at > org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66) > at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126) > at > org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104) > at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57) > at > org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33) > at TransactionException.main(TransactionException.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) > at java.lang.Thread.run(Thread.java:748) > {noformat} > I have created a minimal example available on > [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached > to this issue. > h3. Findings > * The exception doesn't occur for smaller query results > * This seems to be a regression as it works as expected with Jena 3.8.0 > * Using {{git bisect}} I have identified the commit where this starts to > happen: > [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Hash files of Apache Jena releases
Temporary fixup done. Andy On 24/10/2018 21:54, Andy Seaborne wrote: I can fix up the current dist/binaries as per (1), if that's OK. As a fixup, this is not assuming it is the long term decision. For 3.8.0, the format was the format of Linux sha512sum (not the other checksums) - that includes the file name and can be verify by sha512sum --verify, and end in a newline. Maven generated chksums are just the checksum without giving the file name. This the style used in the maven artifacts and and the source-release sha512. Andy On 24/10/2018 21:07, Andy Seaborne wrote: The report is correct. When we moved to SHA512 we had to additionally create them. Then for 3.9.0, the Apache release profile did it for source-release. Doing it for source-release is the only required part in ASF release policy. We can either 1: put back the addition step to add SHA512 the binaries 2: change the download page to reference the sha1's I'm inclined to do (1) to keep the download page clean (it needs the source-release being made more prominent IMO; this binaries downloads are nowadays rather less important than the maven channel). Does anyone know of a standalone way to do "mvn dependency:copy-dependencies"? If there is such a thing, we can consider using the maven channel for non-maven usage. Andy On 24/10/2018 16:38, Lucas Werkmeister wrote: Hi! I’m not sure if this email address is the best way to report the issue (I found it when trying to “improve this page” using the link in the upper right corner), but FYI: the Apache Jena Releases page [1] links to SHA512 files for the downloads, but those files don’t actually exist; instead, according to the automatically generated index [2], there are SHA1 files. You might want to change your CGI script to link to those instead. Best regards, Lucas Werkmeister [1]: https://jena.apache.org/download/index.cgi [2]: https://www.apache.org/dist/jena/binaries/
CMS diff: Jena-related projects and tools
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/about_jena%2Fcontributions.mdtext Greg Albiston Index: trunk/content/about_jena/contributions.mdtext === --- trunk/content/about_jena/contributions.mdtext (revision 1844793) +++ trunk/content/about_jena/contributions.mdtext (working copy) @@ -31,4 +31,6 @@ Persistence Annotations 4 RDF | Persistence Annotation for RDF (PAR) is a set of annotations and an entity manager that provides JPA like functionality on top of an RDF store while accounting for and exploiting the fundamental differences between graph storage and relational storage. PAR introduces three (3) annotations that map a RDF triple (subject, predicate, object) to a Plain Old Java Object (POJO) using Java's dynamic proxy capabilities. | Apache 2.0 | Claude Warren | [PA4RDF at Sourceforge](https://sourceforge.net/projects/pa4rdf/) JenaSecurity | Security (Permissions) wrapper around Jena RDF implementation. | Apache 2.0 | Claude Warren | [JenaSecurity at GitHub](https://github.com/Claudenw/JenaSecurity) Semantic_Forms | Swiss army knife for data management and social networking. | open source | Jean-Marc Vanel | [Semantic_Forms](https://github.com/jmvanel/semantic_forms) -JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL endpoint (or Jena Model) as the data store. Presents graph data as relational data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at GitHub](https://github.com/Claudenw/jdbc4sparql) \ No newline at end of file +JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL endpoint (or Jena Model) as the data store. Presents graph data as relational data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at GitHub](https://github.com/Claudenw/jdbc4sparql) +GeoSPARQL Jena | Implementation of GeoSPARQL 1.0 standard using Apache Jena for SPARQL query or API. | Apache 2.0 | Greg Albiston and Haozhe Chen | [geosparql-jena at GitHub](https://github.com/galbiston/geosparql-jena) +GeoSPARQL Fuseki | HTTP server application compliant with the GeoSPARQL standard using GeoSPARQL Jena library and Apache Jena Fuseki server | Apache 2.0 | Greg Albiston | [geosparql-fuseki at GitHub](https://github.com/galbiston/geosparql-fuskei) \ No newline at end of file