[
https://issues.apache.org/jira/browse/JENA-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15755341#comment-15755341
]
ASF GitHub Bot commented on JENA-1267:
--------------------------------------
Github user afs commented on the issue:
https://github.com/apache/jena/pull/197
> Is the basic idea of jena-integration-tests to provide a place for
inter-module tests?
The driver is that testing remote operations needs a SPARQL server but that
is not a dependency of the code, only of the tests. However, Fuseki isn't
built at this point in the build process.
jena-rdfconnection goes into the apache-jena-libs and apache-jena artifacts
but Fuseki is built after those.
This must be a common need in system so if there is a better common
pattern, then I'm happy to switch to that.
There are a number of ways this could be done:
1. Build modules in a different order - e.g. do building steps before
delivery modules.
2. Put the tests in Fuseki
3. As here, a specific module.
4. Use a previous version of Fuseki.
(1) works in this case but it may not work out whereas the idea of an
integration testing module, seems general. (2) is a less clean version of (1);
this is already done in a small way - those can be moved now. (4) seems
accident prone.
So (3) looks the best way and may be applicable for other situations. It
may even to help unblock evolution of the legacy module/packing structure (the
old Turtle reader in jena-core is needed for assembler tests - I haven't had a
chance to try yet).
> RDFConnection
> -------------
>
> Key: JENA-1267
> URL: https://issues.apache.org/jira/browse/JENA-1267
> Project: Apache Jena
> Issue Type: New Feature
> Affects Versions: Jena 3.1.1
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Fix For: Jena 3.2.0
>
>
> RDFConnection is an API to bring together the 3 parts of SPARQL : Query,
> Update and Graph Store Protocol.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
