[jira] [Resolved] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved JENA-1457. - Resolution: Fixed Fix Version/s: Jena 3.7.0 > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: Jena 3.7.0 > > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356023#comment-16356023 ] ASF GitHub Bot commented on JENA-1457: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/352 > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356022#comment-16356022 ] ASF subversion and git services commented on JENA-1457: --- Commit 8567e272d8d1bb33284ee2c4bdba056b69d76139 in jena's branch refs/heads/master from [~cla...@xenei.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8567e27 ] JENA-1457 Fix graph contract test transaction usage this closes #352 > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351747#comment-16351747 ] ASF GitHub Bot commented on JENA-1457: -- GitHub user Claudenw opened a pull request: https://github.com/apache/jena/pull/352 Fixes for JENA-1457 - Fix graph contract test transaction usage Fixed removed unnecessary "new Runnable()" constructs and reverted JSONInput.java to master branch version. As part of addition ot JENA-1457 this updates junit-contracts to version 0.2.0 Also added .recommenders directory to RAT exclude. (it was already in .gitignore) You can merge this pull request into a Git repository by running: $ git pull https://github.com/Claudenw/jena FixGraphContractTestTransactionUsage Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/352.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #352 commit 50703b41060227741304d5e6e236ef57c10b6df8 Author: Claude Warren <claude@...> Date: 2017-12-29T20:45:33Z fixed Graph tests commit 20b78ae0ddc7a2102602a28f9ed3f48a40c99a1b Author: Andy Seaborne <andy@...> Date: 2017-12-18T14:49:40Z Blank node labels for JSON Result Set reading commit 30989a54b4aec3453152ce970832eea8e8acc0d3 Author: Claude Warren <claude@...> Date: 2018-01-20T10:10:53Z Merge remote-tracking branch 'apache/master' into FixGraphContractTestTransactionUsage commit fa23c25835247e2586ed37ad491c45322dca45b6 Author: Claude Warren <claude@...> Date: 2018-01-20T10:40:33Z Added .recommenders to RAT exclusion. commit 185badb543a6290ae533a0142f416ab4f466043b Author: Claude Warren <claude@...> Date: 2018-01-20T21:29:36Z Updated version number for junit-contracts to 0.2.0 commit 363e95818710ec45352bf8e1330dcf3bf1f59686 Author: Claude Warren <claude@...> Date: 2018-01-21T12:13:23Z Merge branch 'master' into FixGraphContractTestTransactionUsage commit 02ae2697dbc265c98c21885d284a7c0210125a5c Author: Claude Warren <claude@...> Date: 2018-02-04T10:56:18Z Removed unnecsssary "new Runnable()" constructs commit 567f40531b02ea4808a51837ae8005b98da76886 Author: Claude Warren <claude@...> Date: 2018-02-04T11:05:28Z Merge branch 'master' into FixGraphContractTestTransactionUsage commit 0d0beae44bf92ddb7b4b755d58819621d7163d75 Author: Claude Warren <claude@...> Date: 2018-02-04T11:11:46Z reverted to master version > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[
https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333649#comment-16333649
]
ASF GitHub Bot commented on JENA-1457:
--
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/343#discussion_r162823649
--- Diff:
jena-core/src/test/java/org/apache/jena/graph/GraphWithPerformContractTest.java
---
@@ -68,7 +68,13 @@ public void testPerformAdd_Triple() {
g.performAdd(triple("S3 P3 O3"));
txnCommit(g);
GL.assertEmpty();
+ txnRun( g, new Runnable() {
--- End diff --
There is no need to explicitly have a `Runnable` here or in the other uses:
```
txnRun( g, ()->assertTrue(g.contains(triple("S3 P3 O3"))) );
```
makes the tests shorter and clearer.
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
> Issue Type: Bug
> Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.
> Specifically, if the graph supports transactions all actions should be
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it
> will fail if transactions are not properly used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[
https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333648#comment-16333648
]
ASF GitHub Bot commented on JENA-1457:
--
Github user afs commented on the issue:
https://github.com/apache/jena/pull/343
Yes - there are problems with JSONInput. This is visible in the {{.patch}}
form. It looks like changes were copied from Jena master and separately
committed.
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
> Issue Type: Bug
> Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.
> Specifically, if the graph supports transactions all actions should be
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it
> will fail if transactions are not properly used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333517#comment-16333517 ] ASF GitHub Bot commented on JENA-1457: -- GitHub user Claudenw opened a pull request: https://github.com/apache/jena/pull/343 Fixes for JENA-1457 I had some issues with merging into my branch so I created this pull to ensure that only expected files were updated. As part of addition ot JENA-1457 this updates junit-contracts to version 0.2.0 Also added .recommenders directory to RAT exclude. (it was already in .gitignore) You can merge this pull request into a Git repository by running: $ git pull https://github.com/Claudenw/jena master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/343.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #343 commit 50703b41060227741304d5e6e236ef57c10b6df8 Author: Claude Warren <claude@...> Date: 2017-12-29T20:45:33Z fixed Graph tests commit 20b78ae0ddc7a2102602a28f9ed3f48a40c99a1b Author: Andy Seaborne <andy@...> Date: 2017-12-18T14:49:40Z Blank node labels for JSON Result Set reading commit 30989a54b4aec3453152ce970832eea8e8acc0d3 Author: Claude Warren <claude@...> Date: 2018-01-20T10:10:53Z Merge remote-tracking branch 'apache/master' into FixGraphContractTestTransactionUsage commit fa23c25835247e2586ed37ad491c45322dca45b6 Author: Claude Warren <claude@...> Date: 2018-01-20T10:40:33Z Added .recommenders to RAT exclusion. commit 185badb543a6290ae533a0142f416ab4f466043b Author: Claude Warren <claude@...> Date: 2018-01-20T21:29:36Z Updated version number for junit-contracts to 0.2.0 commit 363e95818710ec45352bf8e1330dcf3bf1f59686 Author: Claude Warren <claude@...> Date: 2018-01-21T12:13:23Z Merge branch 'master' into FixGraphContractTestTransactionUsage commit 554a7dc86a4967a9971354f4d7b19354a9d07402 Author: Claude Warren <claude@...> Date: 2018-01-21T13:12:19Z fixes JENA-1457 Removed incorrect JSONInput.java > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren reassigned JENA-1457: --- Assignee: Claude Warren > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307263#comment-16307263 ] A. Soroka commented on JENA-1457: - Just to be extra-clear: TIM doesn't require explicit transactions, but any non-transactional calls on it get auto-wrapped per call into single-call-payload transactions. Expensive and slow! So one can mix explicit and non-explicit transactional behavior against TIM (there really is no non-transactional behavior for TIM), but users are well-advised to be as explicit as possible. So it seems like TIM or TDB2 graphs are always transactional and other dataset impls, not so much, but I don't know that we can represent very well that at this point in the API/contracts. It seems like that boat has sailed on the same tide that sent immutable graphs out to sea. Maybe we can think about representing transactionality differently in a new API? > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307222#comment-16307222 ] Andy Seaborne commented on JENA-1457: - Some graphs support transactional and non-transactional behaviour. The contract tests have no way to be configured. At the moment, TDB2 requires explicit transactions and it's the only one of the project's storage components that does. TIM and TDB1 do not require transactions, though once a TDB1 dataset has been used transactionally, it must always be used transactionally. This does not apply to TIM. As we have seen on dev@, some tests are not about the graph contract. If two graphs are involved, the contract says nothing about their interacting behaviour, and shouldn't because the choices are part of why one storage component is chosen over another . (Graph capabilities can not capture this as it is a closed up-front set of options. > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306603#comment-16306603 ] Claude Warren commented on JENA-1457: - the txnBegin and other methods determine if the graph supports transactions and uses them otherwise no transaction code is called. > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
The test code determines if the graph supports transactions and uses them if they are supported. On Fri, Dec 29, 2017 at 10:29 PM, Andy Seaborne (JIRA) <j...@apache.org> wrote: > > [ https://issues.apache.org/jira/browse/JENA-1457?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel=16306579#comment-16306579 ] > > Andy Seaborne commented on JENA-1457: > - > > "supportsTransactions" does not mean "must use transactions". > > The details depend on the implementation. > > > Graph contract tests do not properly support transactions > > - > > > > Key: JENA-1457 > > URL: https://issues.apache.org/jira/browse/JENA-1457 > > Project: Apache Jena > > Issue Type: Bug > > Components: Core > >Reporter: Claude Warren > >Priority: Minor > > > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > > The easiest test for this is to test the GraphTxnTDB implementation as > it will fail if transactions are not properly used. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions
[ https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306579#comment-16306579 ] Andy Seaborne commented on JENA-1457: - "supportsTransactions" does not mean "must use transactions". The details depend on the implementation. > Graph contract tests do not properly support transactions > - > > Key: JENA-1457 > URL: https://issues.apache.org/jira/browse/JENA-1457 > Project: Apache Jena > Issue Type: Bug > Components: Core >Reporter: Claude Warren >Priority: Minor > > The Contract test for Graphs do not properly support transactions. > Specifically, if the graph supports transactions all actions should be > enclosed within a transaction. > The easiest test for this is to test the GraphTxnTDB implementation as it > will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JENA-1457) Graph contract tests do not properly support transactions
Claude Warren created JENA-1457: --- Summary: Graph contract tests do not properly support transactions Key: JENA-1457 URL: https://issues.apache.org/jira/browse/JENA-1457 Project: Apache Jena Issue Type: Bug Components: Core Reporter: Claude Warren Priority: Minor The Contract test for Graphs do not properly support transactions. Specifically, if the graph supports transactions all actions should be enclosed within a transaction. The easiest test for this is to test the GraphTxnTDB implementation as it will fail if transactions are not properly used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
jena-core tests and contract tests
Claude, This is for information - I think I've solved the problem. A couple of days ago I corrected the surefire test setup to explicitly name TestPackage (was com.hp.hpl. ...). includes includeorg/apache/jena/test/TestPackage.java/include include**/*_CS.java/include /includes and now we have: https://builds.apache.org/job/Jena_Development_Test/1992/testReport/ The two tests failing have inner test classes in TestAssemblerHelp and TestAssemblerGroup to be loaded so that the tests which try to detect that before they aren't loaded and after some assembler action are loaded then fail. Is that possible? Could the contract code be causing an early load of the inner classes to scan them? Solution: there is a static method called on a class loaded buy an assembler every time loadClass is used. I got that to set I was loaded flag instead. Andy
Re: jena-core tests and contract tests
It is possible (and probable) that the contract code scanner is loading them. At one point I thought I was loading classes but not initializing them. I will look into this. Claude On Mon, Jul 13, 2015 at 1:27 PM, Andy Seaborne a...@apache.org wrote: Claude, This is for information - I think I've solved the problem. A couple of days ago I corrected the surefire test setup to explicitly name TestPackage (was com.hp.hpl. ...). includes includeorg/apache/jena/test/TestPackage.java/include include**/*_CS.java/include /includes and now we have: https://builds.apache.org/job/Jena_Development_Test/1992/testReport/ The two tests failing have inner test classes in TestAssemblerHelp and TestAssemblerGroup to be loaded so that the tests which try to detect that before they aren't loaded and after some assembler action are loaded then fail. Is that possible? Could the contract code be causing an early load of the inner classes to scan them? Solution: there is a static method called on a class loaded buy an assembler every time loadClass is used. I got that to set I was loaded flag instead. Andy -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: jena-core tests and contract tests
On 13/07/15 13:53, Claude Warren wrote: It is possible (and probable) that the contract code scanner is loading them. At one point I thought I was loading classes but not initializing them. I will look into this. Not urgent as my fix seems to have fixed it [famous last words]. (and now maven versions and excessive javadoc warnings on unknown tags that aren't even used!) The assembler test code was using static initializers to set a I've loaded flag. Andy Claude On Mon, Jul 13, 2015 at 1:27 PM, Andy Seaborne a...@apache.org wrote: Claude, This is for information - I think I've solved the problem. A couple of days ago I corrected the surefire test setup to explicitly name TestPackage (was com.hp.hpl. ...). includes includeorg/apache/jena/test/TestPackage.java/include include**/*_CS.java/include /includes and now we have: https://builds.apache.org/job/Jena_Development_Test/1992/testReport/ The two tests failing have inner test classes in TestAssemblerHelp and TestAssemblerGroup to be loaded so that the tests which try to detect that before they aren't loaded and after some assembler action are loaded then fail. Is that possible? Could the contract code be causing an early load of the inner classes to scan them? Solution: there is a static method called on a class loaded buy an assembler every time loadClass is used. I got that to set I was loaded flag instead. Andy
Re: contract tests
Claude, I trying to understand the contract testing. I have been looking at GraphMem_CS and DeltaTest mainly. Are they good examples? What's the way to find out what classes are discovered and tested? contract-test-maven-plugin -- what's the role of this plugin? because the surefire setup has: include**/*_CS.java/include There is various logging messages now as well but some seem to come from include the Contract engine. Should they be suppressed? see for example: https://builds.apache.org/user/andy/my-views/view/Jena/job/Jena_Development_Test/lastSuccessfulBuild/consoleFull Andy
Re: contract tests
On 20/05/15 18:48, Claude Warren wrote: parallel for now, but I expect we would move a fair number of tests to it as a replacement. I'm not so sure replacement is the right thing to do and I'd welcome veryone's thoughts. It would introduce a signifcant dependency on org.xenei:junit-contracts. With all due respect, having longterm (years!) jena testing depend on that is not ideal. Andy On Wed, May 20, 2015 at 10:25 AM, Andy Seaborne a...@apache.org wrote: On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Seems like a good idea - would this be in parallel to the existing tests, or a partial replacement? Andy Claude
Re: contract tests
On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Claude Claude, There are some rough edges: 1/ The POM has been converted from spaces to tabs around commit 608c2b4 2/ There are new dependencies, and recursive some are not Apache Licensed. Is there anything that should go in LICENSE or NOTICE, even if that comes via org.apache.maven? 3/ Why does testing depend on commons-cli? PR#76 proposes use of commons:common-cli (different version) which caused me to see that. 4/ Can we have version mgt in jena-parent please? All other version mgt or non-jena dependencies is done there (jena-* ones have to be done explicitly for the release plug-in) Andy
Re: contract tests
I'll have to go back and review the dependency tree. The contract tests should only introduce: 1) a junit runner and associated annotations. 2) a maven mojo to report on the testing structure. I think the client requirement comes in becaue there is a command line version of the mojo. I'll see what I can do about extracting that into a command line module separate from the main code -- shouldn't be hard. As for the non-apache licensed pieces is there a way to generate a list of them? All the xenei code is apache, the only other bits should be junit and maven mojo depdendencies. Claude On Thu, Jun 11, 2015 at 12:36 PM, Andy Seaborne a...@apache.org wrote: On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Claude Claude, There are some rough edges: 1/ The POM has been converted from spaces to tabs around commit 608c2b4 2/ There are new dependencies, and recursive some are not Apache Licensed. Is there anything that should go in LICENSE or NOTICE, even if that comes via org.apache.maven? 3/ Why does testing depend on commons-cli? PR#76 proposes use of commons:common-cli (different version) which caused me to see that. 4/ Can we have version mgt in jena-parent please? All other version mgt or non-jena dependencies is done there (jena-* ones have to be done explicitly for the release plug-in) Andy -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests
On 11/06/15 14:35, Claude Warren wrote: I'll have to go back and review the dependency tree. The contract tests should only introduce: 1) a junit runner and associated annotations. 2) a maven mojo to report on the testing structure. I think the client requirement comes in becaue there is a command line version of the mojo. I'll see what I can do about extracting that into a command line module separate from the main code -- shouldn't be hard. As for the non-apache licensed pieces is there a way to generate a list of them? All the xenei code is apache, the only other bits should be junit and maven mojo depdendencies. Claude Hi Claude, I looked at the output of mvn dependency:tree and for org.xenei, org.mockito, here is an extract of output: +- org.xenei:junit-contracts:jar:0.1.2:test | +- commons-cli:commons-cli:jar:1.2:test | \- commons-io:commons-io:jar:2.4:test +- org.xenei:contract-test-maven-plugin:jar:0.1.2:test | +- org.apache.maven:maven-plugin-api:jar:3.2.5:test | | +- org.apache.maven:maven-model:jar:3.2.5:test | | +- org.apache.maven:maven-artifact:jar:3.2.5:test | | \- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.0.M1:test | | +- javax.enterprise:cdi-api:jar:1.0:test | | | \- javax.annotation:jsr250-api:jar:1.0:test | | \- org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.3.0.M1:test | +- org.apache.maven:maven-core:jar:3.2.5:test | | +- org.apache.maven:maven-settings:jar:3.2.5:test | | +- org.apache.maven:maven-settings-builder:jar:3.2.5:test | | +- org.apache.maven:maven-repository-metadata:jar:3.2.5:test | | +- org.apache.maven:maven-model-builder:jar:3.2.5:test | | +- org.apache.maven:maven-aether-provider:jar:3.2.5:test | | | \- org.eclipse.aether:aether-spi:jar:1.0.0.v20140518:test | | +- org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:test | | +- org.eclipse.aether:aether-api:jar:1.0.0.v20140518:test | | +- org.eclipse.aether:aether-util:jar:1.0.0.v20140518:test | | +- org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3:test | | | +- javax.inject:javax.inject:jar:1:test | | | \- aopalliance:aopalliance:jar:1.0:test | | +- org.codehaus.plexus:plexus-interpolation:jar:1.21:test | | +- org.codehaus.plexus:plexus-utils:jar:3.0.20:test | | +- org.codehaus.plexus:plexus-classworlds:jar:2.5.2:test | | +- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:test | | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:test | | \- org.sonatype.plexus:plexus-cipher:jar:1.4:test | \- org.apache.maven:maven-compat:jar:3.2.5:test | \- org.apache.maven.wagon:wagon-provider-api:jar:2.8:test +- org.mockito:mockito-all:jar:1.9.5:test On Thu, Jun 11, 2015 at 12:36 PM, Andy Seaborne a...@apache.org wrote: On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Claude Claude, There are some rough edges: 1/ The POM has been converted from spaces to tabs around commit 608c2b4 2/ There are new dependencies, and recursive some are not Apache Licensed. Is there anything that should go in LICENSE or NOTICE, even if that comes via org.apache.maven? 3/ Why does testing depend on commons-cli? PR#76 proposes use of commons:common-cli (different version) which caused me to see that. 4/ Can we have version mgt in jena-parent please? All other version mgt or non-jena dependencies is done there (jena-* ones have to be done explicitly for the release plug-in) Andy
Contract tests.
I have merged the contract tests into the main code branch. There is an overview of contract tests on the wiki at https://cwiki.apache.org/confluence/display/JENA/Contract+Tests -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests
On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Seems like a good idea - would this be in parallel to the existing tests, or a partial replacement? Andy Claude
Re: contract tests
parallel for now, but I expect we would move a fair number of tests to it as a replacement. On Wed, May 20, 2015 at 10:25 AM, Andy Seaborne a...@apache.org wrote: On 19/05/15 20:25, Claude Warren wrote: There is a set of contract tests (and test helpers) on the add-contract-tests branch. That branch works and has minimal change from the current tests. Those changes are adding the junit-contract runner and plugins. It makes no change to the execution. The problem that I am having is keeping it up to date with the current change rate of the Jena packages. Granted the contract tests are only implemented for the jena-core module, we have been keeing the entire suite up to date. Is there anyone that has any objection to moving the contract tests to the main code branch? Seems like a good idea - would this be in parallel to the existing tests, or a partial replacement? Andy Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests.
Thanks for the explanation Claude! Fetched the code from git but will only be able to take a look on it on Wednesday due to a local conference. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Assuming that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather than _CT, just to follow a convention. Bruno From: Claude Warren cla...@xenei.com To: dev@jena.apache.org; Bruno P. Kinoshita ki...@apache.org Sent: Monday, April 27, 2015 6:33 PM Subject: contract tests. I have added a contract testing branch and have added the contract tests for all graphs in the core code. I also have contract tests for several other interfaces defined but no suites to exercise them. I recall a recent conversation where tile names were given TS_ prefix for test suite. I am thinking of giving the contract test suite classes a CT_ prefix (Contract Test). Thoughts? Oh. As an outline: Contract tests are annotated with @Contract and define the contracts for a specific interface listed in the @Contract annotation. e.g. @Contract(Graph.class) indicates contract test for the Graph interface. I normally name these with the word Contract in the class name. e.g. GraphContractTest.java Contract test suites are annotated with @ContractImpl and @RunWith(ContractSuite.class). The @ContractImpl annotation identifies the class under test. e.g. @ContractImpl(CollectionGraph) indicates that CollectionGraph is the implementation under test. These are the ones I am thinking of naming with a CT_ prefix (CT_CollectionGraphTest). These tests generally have one method (a method to provide a producer of the class under test. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests.
On the other side of the discussion I would prefer that TC and TS be suffixes so we can find all tests for common componetns by name. On Mon, Apr 27, 2015 at 10:53 AM, Bruno P. Kinoshita ki...@apache.org wrote: Thanks for the explanation Claude! Fetched the code from git but will only be able to take a look on it on Wednesday due to a local conference. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Assuming that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather than _CT, just to follow a convention. Bruno From: Claude Warren cla...@xenei.com To: dev@jena.apache.org; Bruno P. Kinoshita ki...@apache.org Sent: Monday, April 27, 2015 6:33 PM Subject: contract tests. I have added a contract testing branch and have added the contract tests for all graphs in the core code. I also have contract tests for several other interfaces defined but no suites to exercise them. I recall a recent conversation where tile names were given TS_ prefix for test suite. I am thinking of giving the contract test suite classes a CT_ prefix (Contract Test). Thoughts? Oh. As an outline: Contract tests are annotated with @Contract and define the contracts for a specific interface listed in the @Contract annotation. e.g. @Contract(Graph.class) indicates contract test for the Graph interface. I normally name these with the word Contract in the class name. e.g. GraphContractTest.java Contract test suites are annotated with @ContractImpl and @RunWith(ContractSuite.class). The @ContractImpl annotation identifies the class under test. e.g. @ContractImpl(CollectionGraph) indicates that CollectionGraph is the implementation under test. These are the ones I am thinking of naming with a CT_ prefix (CT_CollectionGraphTest). These tests generally have one method (a method to provide a producer of the class under test. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests.
I was thinking of a case where there are multiple files in a directory like. TS_foo.java TC_foo.java fooTest.java CT_foo.java TS_bar.java TC_bar.java barTest.java CT_bar.java The current naming will generate a list of files like: barTest.java CT_bar.java CT_foo.java fooTest.java TC_bar.java TC_foo.java TS_bar.java TS_foo.java but putting the ??_ a the end as _?? would create a list like: barTest.java bar_CT.java bar_TC.java bar_TS.java fooTest.java foo_CT.java foo_TC.java foo_TS.java I think that when looking for all that tests for foo the latter list makes it easier. But I'm not wedded to it. Just my opinion. Claude On Mon, Apr 27, 2015 at 1:29 PM, Andy Seaborne a...@apache.org wrote: On 27/04/15 13:16, Claude Warren wrote: On the other side of the discussion I would prefer that TC and TS be suffixes so we can find all tests for common componetns by name. (not worried about prefix/suffix) Don't quite follow that point. The surefire (for ARQ) setup has include**/TS_*.java/include include**/TC_Scripted.java/include include**/TC_DAWG.java/include Andy On Mon, Apr 27, 2015 at 10:53 AM, Bruno P. Kinoshita ki...@apache.org wrote: Thanks for the explanation Claude! Fetched the code from git but will only be able to take a look on it on Wednesday due to a local conference. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Assuming that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather than _CT, just to follow a convention. Bruno From: Claude Warren cla...@xenei.com To: dev@jena.apache.org; Bruno P. Kinoshita ki...@apache.org Sent: Monday, April 27, 2015 6:33 PM Subject: contract tests. I have added a contract testing branch and have added the contract tests for all graphs in the core code. I also have contract tests for several other interfaces defined but no suites to exercise them. I recall a recent conversation where tile names were given TS_ prefix for test suite. I am thinking of giving the contract test suite classes a CT_ prefix (Contract Test). Thoughts? Oh. As an outline: Contract tests are annotated with @Contract and define the contracts for a specific interface listed in the @Contract annotation. e.g. @Contract(Graph.class) indicates contract test for the Graph interface. I normally name these with the word Contract in the class name. e.g. GraphContractTest.java Contract test suites are annotated with @ContractImpl and @RunWith(ContractSuite.class). The @ContractImpl annotation identifies the class under test. e.g. @ContractImpl(CollectionGraph) indicates that CollectionGraph is the implementation under test. These are the ones I am thinking of naming with a CT_ prefix (CT_CollectionGraphTest). These tests generally have one method (a method to provide a producer of the class under test. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: contract tests.
On 27/04/15 13:16, Claude Warren wrote: On the other side of the discussion I would prefer that TC and TS be suffixes so we can find all tests for common componetns by name. (not worried about prefix/suffix) Don't quite follow that point. The surefire (for ARQ) setup has include**/TS_*.java/include include**/TC_Scripted.java/include include**/TC_DAWG.java/include Andy On Mon, Apr 27, 2015 at 10:53 AM, Bruno P. Kinoshita ki...@apache.org wrote: Thanks for the explanation Claude! Fetched the code from git but will only be able to take a look on it on Wednesday due to a local conference. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Assuming that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather than _CT, just to follow a convention. Bruno From: Claude Warren cla...@xenei.com To: dev@jena.apache.org; Bruno P. Kinoshita ki...@apache.org Sent: Monday, April 27, 2015 6:33 PM Subject: contract tests. I have added a contract testing branch and have added the contract tests for all graphs in the core code. I also have contract tests for several other interfaces defined but no suites to exercise them. I recall a recent conversation where tile names were given TS_ prefix for test suite. I am thinking of giving the contract test suite classes a CT_ prefix (Contract Test). Thoughts? Oh. As an outline: Contract tests are annotated with @Contract and define the contracts for a specific interface listed in the @Contract annotation. e.g. @Contract(Graph.class) indicates contract test for the Graph interface. I normally name these with the word Contract in the class name. e.g. GraphContractTest.java Contract test suites are annotated with @ContractImpl and @RunWith(ContractSuite.class). The @ContractImpl annotation identifies the class under test. e.g. @ContractImpl(CollectionGraph) indicates that CollectionGraph is the implementation under test. These are the ones I am thinking of naming with a CT_ prefix (CT_CollectionGraphTest). These tests generally have one method (a method to provide a producer of the class under test. Now that I think about it I think the CT should go at the end as CollectionGraph_CT that way all the CollectionGraph tests would be together and easy to find in a directory listing. Claude -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
contract tests: modelCon:getBag, modelCon.getSeq() and modelCon.getAlt()
The javadoc for the modelCon methods getBag(), getSeq() and getAlt() indicate that the returned resource should exist before the method is called. If the resource does not exist, the default implementation seems to create one. However the resulting resources are different from the createBag, createSeq, and createAlt methods in that the returned resource is not part of a resource, RDF.type, X statement and resource.getModel() does not return the original model. I would have expected that the methods would return null if the objects did not exist in the model. However, since it doesn't should these methods be equivalent to the createX versions and add the statement and return the model? If it should not return the model then I assume that it should return a new model of some type (e.g. a model that does not have any statements in it) However, this turns out I will update the documentation and the test cases. Claude -- I like: Like Like - The likeliest place on the webhttp://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
