Re: Building with Java9

2018-02-05 Thread Lorenz B. 
Well, I read about this some time ago and was wondering how many people
are really aware of the fact that no more security updates will be
delivered 6 month after the release of a new version. Most people in our
group are still working on Java 8, if not necessary probably nobody here
will upgrade until the next LTS.

Is anybody of you using features from Java 9? The only things that I
find interesting are some extended Stream functions like takeWhile,
dropWhile, etc. Who is using the modularity feature?


Cheers,

Lorenz


On 05.02.2018 17:41, ajs6f wrote:
> Ditto (haven't been paying much attention).
>
> A six month cycle is pretty fast, in some ways. At least it will be if we 
> have to do a lot of work for each version.
>
> ajs6f
>
>> On Feb 5, 2018, at 11:34 AM, Andy Seaborne  wrote:
>>
>> I hadn't grok'ed (or, to be honest, paid attention to) the details:
>>
>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
>>
>> Java 8 LTS -> Java 11 LTS (Sep 2018)
>>
>> then only four months until end of LTS for Java8.
>>
>>Andy

[jira] [Resolved] (JENA-1476) Stop using javax.xml.bind.DatatypeConverter

2018-02-05 Thread Andy Seaborne (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1476.
-
   Resolution: Done
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.7.0

> Stop using javax.xml.bind.DatatypeConverter
> ---
>
> Key: JENA-1476
> URL: https://issues.apache.org/jira/browse/JENA-1476
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> {{javax.xml.bind}} is not available by default in Java9.
> Jena's use is only hex/base64 translation.
> commons-codec has the necessary code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (JENA-1476) Stop using javax.xml.bind.DatatypeConverter

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351544#comment-16351544
 ] 

Andy Seaborne edited comment on JENA-1476 at 2/5/18 10:08 PM:
--

The package {{javax.xml.bind}} is considered part of JavaEE and is not 
available by default as a module for JavaSE in Java9. It will be removed from 
JavaSE in Java11 ([JEP 320| http://openjdk.java.net/jeps/320]).


was (Author: andy.seaborne):
The package `javax.xml.bind` is considered part of JavaEE and is not available 
by default as a module for JavaSE in Java9. It will be removed from JavaSE in 
Java11 ([JEP 320](http://openjdk.java.net/jeps/320).

> Stop using javax.xml.bind.DatatypeConverter
> ---
>
> Key: JENA-1476
> URL: https://issues.apache.org/jira/browse/JENA-1476
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> {{javax.xml.bind}} is not available by default in Java9.
> Jena's use is only hex/base64 translation.
> commons-codec has the necessary code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1476) Stop using javax.xml.bind.DatatypeConverter

2018-02-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352994#comment-16352994
 ] 

ASF GitHub Bot commented on JENA-1476:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/351


> Stop using javax.xml.bind.DatatypeConverter
> ---
>
> Key: JENA-1476
> URL: https://issues.apache.org/jira/browse/JENA-1476
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> {{javax.xml.bind}} is not available by default in Java9.
> Jena's use is only hex/base64 translation.
> commons-codec has the necessary code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #351: JENA-1476: Switch javax.xml.bind.DatatypeConverter t...

2018-02-05 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/351


---

[jira] [Commented] (JENA-1476) Stop using javax.xml.bind.DatatypeConverter

2018-02-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352992#comment-16352992
 ] 

ASF subversion and git services commented on JENA-1476:
---

Commit e032ed770419ac36de4f7703bf914ab5e7ba67fe in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=e032ed7 ]

JENA-1476: Switch javax.xml.bind.DatatypeConverter to commons-codec


> Stop using javax.xml.bind.DatatypeConverter
> ---
>
> Key: JENA-1476
> URL: https://issues.apache.org/jira/browse/JENA-1476
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> {{javax.xml.bind}} is not available by default in Java9.
> Jena's use is only hex/base64 translation.
> commons-codec has the necessary code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1476) Stop using javax.xml.bind.DatatypeConverter

2018-02-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352993#comment-16352993
 ] 

ASF subversion and git services commented on JENA-1476:
---

Commit f1ed0e2b7530aae74194e0cc6cb2996a10b1d00f in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=f1ed0e2 ]

JENA-1476: Merge commit 'refs/pull/351/head' of github.com:apache/jena

This closes #351.


> Stop using javax.xml.bind.DatatypeConverter
> ---
>
> Key: JENA-1476
> URL: https://issues.apache.org/jira/browse/JENA-1476
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
>
> {{javax.xml.bind}} is not available by default in Java9.
> Jena's use is only hex/base64 translation.
> commons-codec has the necessary code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1478) DifferenceDatasetGraph.contains

2018-02-05 Thread Andy Seaborne (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1478:
---

Assignee: Andy Seaborne

> DifferenceDatasetGraph.contains
> ---
>
> Key: JENA-1478
> URL: https://issues.apache.org/jira/browse/JENA-1478
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> (Assuming "difference is set-difference" not symmetric difference")
> defined "contains" as 
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return both(dsg -> dsg.contains(g, s, p, o));
> }
> {noformat}
> This should be:
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return getLeft().contains(g, s, p, o) && ! getRight().contains(g, s, p, 
> o);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1478) DifferenceDatasetGraph.contains

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352987#comment-16352987
 ] 

Andy Seaborne commented on JENA-1478:
-

I think the most important point design point is that transaction involvement 
is possible but not all combinations make sense.

DBOE is a bit better because its possible to define groups of components that 
comprise a transaction. That isn't the same as having one component in multiple 
groupings which is what is required for an ideal solution, as is true nested 
transactions.

There are several cases that are viable:
* The dyadic dataset is set up, and the transaction is done on the dyadic 
dataset, there being no transactions on the components.
* The dyadic dataset is setup inside transactions on both elements - in which 
case, a transaction on the dyadic dataset does not make sense.

Other case like the mixed case of one dataset in a transaction and one not, is 
not going to work automatically, the app is going to have to start a 
transaction on the non-active one. 

Only the first case - transaction on the dyadic dataset and component datasets 
not in a transaction for this thread - needs to be covered. The second case is 
outside the dyadic dataset.

If we say "no transactions on the components" while the dyadic has a 
transaction, then the dyadic dataset is a read transaction, which can be 
started as at preset calling {{begin(READ)}}. It does not even need to be 
synchronized.

I'm in the middle of adding {{promote(promoteType)}} so let me keep checking as 
I develop that code. Theer are minor thigns like commit throwing an exception 
but a read transaction can commit.


> DifferenceDatasetGraph.contains
> ---
>
> Key: JENA-1478
> URL: https://issues.apache.org/jira/browse/JENA-1478
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> (Assuming "difference is set-difference" not symmetric difference")
> defined "contains" as 
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return both(dsg -> dsg.contains(g, s, p, o));
> }
> {noformat}
> This should be:
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return getLeft().contains(g, s, p, o) && ! getRight().contains(g, s, p, 
> o);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1389) Return `this` rather than `void` from Dataset

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352957#comment-16352957
 ] 

Andy Seaborne commented on JENA-1389:
-

I find it hard to judge how much the binary incompatibility will be an issue. 
Could we experiment to check its effects?

If users drop in new jars without compiling, either directly, or indirectly 
because a dependency has moved to 3.7.0.  As to much disruption this might 
cause, I can't tell.



> Return `this` rather than `void` from Dataset
> -
>
> Key: JENA-1389
> URL: https://issues.apache.org/jira/browse/JENA-1389
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easytask
>
> Allow method chaining from the org.apache.jena.query.Dataset interface by 
> returning `this` rather than `void` from the following methods.
> # setDefaultModel
> # addNamedModel
> # removeNamedModel
> # replaceNamedModel
> Allowing method chaining would align with the behavior of the add and remove 
> methods in org.apache.jena.rdf.model.Model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (JENA-1418) Upgrade minor dependencies

2018-02-05 Thread A. Soroka (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A. Soroka closed JENA-1418.
---
Resolution: Fixed

> Upgrade minor dependencies
> --
>
> Key: JENA-1418
> URL: https://issues.apache.org/jira/browse/JENA-1418
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>Affects Versions: Jena 3.5.0
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.7.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1389) Return `this` rather than `void` from Dataset

2018-02-05 Thread A. Soroka (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352656#comment-16352656
 ] 

A. Soroka commented on JENA-1389:
-

I think we have agreement that this is not so huge a change that we have to 
wait for 4.0.0. Would we be cool with doing this for 3.7.0? (I would be.)

> Return `this` rather than `void` from Dataset
> -
>
> Key: JENA-1389
> URL: https://issues.apache.org/jira/browse/JENA-1389
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easytask
>
> Allow method chaining from the org.apache.jena.query.Dataset interface by 
> returning `this` rather than `void` from the following methods.
> # setDefaultModel
> # addNamedModel
> # removeNamedModel
> # replaceNamedModel
> Allowing method chaining would align with the behavior of the add and remove 
> methods in org.apache.jena.rdf.model.Model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1479) Fuller testing for subclasses of DyadicDatasetGraph

2018-02-05 Thread A. Soroka (JIRA) 
A. Soroka created JENA-1479:
---

 Summary: Fuller testing for subclasses of DyadicDatasetGraph
 Key: JENA-1479
 URL: https://issues.apache.org/jira/browse/JENA-1479
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Affects Versions: Jena 3.6.0
Reporter: A. Soroka
Assignee: A. Soroka






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Building with Java9

2018-02-05 Thread ajs6f 
Ditto (haven't been paying much attention).

A six month cycle is pretty fast, in some ways. At least it will be if we have 
to do a lot of work for each version.

ajs6f

> On Feb 5, 2018, at 11:34 AM, Andy Seaborne  wrote:
> 
> I hadn't grok'ed (or, to be honest, paid attention to) the details:
> 
> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
> 
> Java 8 LTS -> Java 11 LTS (Sep 2018)
> 
> then only four months until end of LTS for Java8.
> 
>Andy

Re: Building with Java9

2018-02-05 Thread Andy Seaborne 

I hadn't grok'ed (or, to be honest, paid attention to) the details:

http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html

Java 8 LTS -> Java 11 LTS (Sep 2018)

then only four months until end of LTS for Java8.

Andy

[GitHub] jena pull request #353: Refactoring complex methods of classes FBRuleInfGrap...

2018-02-05 Thread santiago-a-vidal 
GitHub user santiago-a-vidal opened a pull request:

https://github.com/apache/jena/pull/353

Refactoring complex methods of classes FBRuleInfGraph and LPRuleStore

Related to no particular issue. This is a behavior-preserving refactoring.

Summary of this pull request:

• We are evaluating a research prototype called Bandago that assists in 
the refactoring of complex methods. Bandago is an Eclipse plugin that 
automatically identifies and refactors a type of code smell called Brain 
Method. A Brain Method centralizes the intelligence of a class and manifests 
itself as a long and complex method that is difficult to understand and 
maintain We have applied Bandago to 2 complex methods of your project, and we 
would like to receive feedback.
• Bandago is very conservative and you should not observe many source 
code changes (only in the affected class).
• The source code (after the refactoring) should behave equivalently to 
the original one.
• As a sanity check, we have run tests before and after Bandago performed 
the refactoring(s) on the project. All tests passed.
• The goal of the refactorings applied is to improve the legibility of 
the refactored method.
• In this case, Bandago refactored the method FBRuleInfGraph.prepare 
extracting fragments of its code into the new methods initializeDeductions, 
initializeTGCCache, and callPreprocessingHook. Also, the method 
LPRuleStore.compileAll() was refactored extracting fragments of its code into 
the new methods addWildCardRules and buildTwoLevelIndices.

Thanks in advance for your help in this evaluation!


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/santiago-a-vidal/jena BandagoRefactorings

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/353.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 #353


commit 5eacd1bf704122dd086dd9e939186de3d134c23f
Author: Santiago Vidal 
Date:   2018-02-05T16:26:50Z

Brain methods of classes FBRuleInfGraph and LPRuleStore automatically
refactored with Bandago




---

[jira] [Commented] (JENA-1478) DifferenceDatasetGraph.contains

2018-02-05 Thread A. Soroka (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352615#comment-16352615
 ] 

A. Soroka commented on JENA-1478:
-

1. [~jaco0646] never confirmed whether my work on JENA-1391 was good for him, 
but I think you are right. Please do go ahead. I'll open a ticket for myself to 
write more tests for the subclasses of {{DyadicDatasetGraph}}.

2. I didn't come to a real understanding of transactional behavior for views, 
period, and certainly not specifically for {{DyadicDatasetGraph}}, but 
certainly, {{null}} returns there are not cool. The question was: if one side 
is in {{READ}}, because the client opened a transaction on the view, and the 
other side is not (perhaps blocked waiting to get a lock) what is the right 
value here? It's not {{READ}} because the view is _not_ in a transaction at 
all. I'm happy for whatever you think is more "ergonomic" for the user. Maybe 
throw a very specific exception? But that feels like a terrible response to a 
reasonable query by the user…

> DifferenceDatasetGraph.contains
> ---
>
> Key: JENA-1478
> URL: https://issues.apache.org/jira/browse/JENA-1478
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> (Assuming "difference is set-difference" not symmetric difference")
> defined "contains" as 
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return both(dsg -> dsg.contains(g, s, p, o));
> }
> {noformat}
> This should be:
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return getLeft().contains(g, s, p, o) && ! getRight().contains(g, s, p, 
> o);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1478) DifferenceDatasetGraph.contains

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352370#comment-16352370
 ] 

Andy Seaborne commented on JENA-1478:
-

{{DyadicDatasetGraph.transactionMode()}}

This can return null. Enums really shouldn't be null.

>From the point of view of {{DyadicDatasetGraph}}, transactions are READ 
>because no changes are allowed.  of course, the underlying dataset can be 
>changing but there isn't transaction support for this anyway.





> DifferenceDatasetGraph.contains
> ---
>
> Key: JENA-1478
> URL: https://issues.apache.org/jira/browse/JENA-1478
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> (Assuming "difference is set-difference" not symmetric difference")
> defined "contains" as 
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return both(dsg -> dsg.contains(g, s, p, o));
> }
> {noformat}
> This should be:
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return getLeft().contains(g, s, p, o) && ! getRight().contains(g, s, p, 
> o);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1478) DifferenceDatasetGraph.contains

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352367#comment-16352367
 ] 

Andy Seaborne commented on JENA-1478:
-

Found during some on-going work on transactions.
I can apply this change as part of that PR if the fix is agreed.


> DifferenceDatasetGraph.contains
> ---
>
> Key: JENA-1478
> URL: https://issues.apache.org/jira/browse/JENA-1478
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> (Assuming "difference is set-difference" not symmetric difference")
> defined "contains" as 
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return both(dsg -> dsg.contains(g, s, p, o));
> }
> {noformat}
> This should be:
> {noformat}
> public boolean contains(Node g, Node s, Node p, Node o) {
> return getLeft().contains(g, s, p, o) && ! getRight().contains(g, s, p, 
> o);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-1473) SKOS inference with Jena

2018-02-05 Thread gillesh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

gillesh resolved JENA-1473.
---
Resolution: Fixed

> SKOS inference with Jena
> 
>
> Key: JENA-1473
> URL: https://issues.apache.org/jira/browse/JENA-1473
> Project: Apache Jena
>  Issue Type: Question
>Reporter: gillesh
>Priority: Minor
>
> Hi,
> I am looking for some advices on how best infer triples related to SKOS.
> The reasoners provided by Jena are only related to OWL and RDFS.
> I currently don't need the whole SKOS vocabulary. For the moment, I mainly 
> need skos:broader, skos:narrower and skos:altLabel but I may need others in 
> the future.
> What would be a clean way to get the triples I want using Jena and SPARQL 
> queries ?
> Create rules and use the general purpose rule engine of Jena 
> ([documentation|https://jena.apache.org/documentation/inference/#rules])?
> I never did any manual inference for the moment so I am quite confused about 
> all this.
> Any help/resources pointing to the right direction would be greatly 
> appreciated.
> Thank you.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1472) Submitting async tasks locks up at the 22nd attempt.

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352169#comment-16352169
 ] 

Andy Seaborne commented on JENA-1472:
-

Releases depend on people-time and people contributing to Jena are volunteers. 
Releases happen every 3-4 months (with the exception that last one was out of 
sequence to release a bug that impacted people new to Jena).

You can help by testing using a development build (they get built automatically 
from master on a daily basis) or building from source.



> Submitting async tasks locks up at the 22nd attempt.
> 
>
> Key: JENA-1472
> URL: https://issues.apache.org/jira/browse/JENA-1472
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> From the users list:
> [https://lists.apache.org/thread.html/4b8c2dc56bc206315e611dbce27ec9a56a36f3437ebefa15f3328fd0@%3Cusers.jena.apache.org%3E]
>  
> Cause: fails to remove old tasks correctly in {{AsyncPool.finished}}. It 
> loops, holding the mutex and so blocking everything else.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1473) SKOS inference with Jena

2018-02-05 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352159#comment-16352159
 ] 

Andy Seaborne commented on JENA-1473:
-

Please use the users mailing list.



> SKOS inference with Jena
> 
>
> Key: JENA-1473
> URL: https://issues.apache.org/jira/browse/JENA-1473
> Project: Apache Jena
>  Issue Type: Question
>Reporter: gillesh
>Priority: Minor
>
> Hi,
> I am looking for some advices on how best infer triples related to SKOS.
> The reasoners provided by Jena are only related to OWL and RDFS.
> I currently don't need the whole SKOS vocabulary. For the moment, I mainly 
> need skos:broader, skos:narrower and skos:altLabel but I may need others in 
> the future.
> What would be a clean way to get the triples I want using Jena and SPARQL 
> queries ?
> Create rules and use the general purpose rule engine of Jena 
> ([documentation|https://jena.apache.org/documentation/inference/#rules])?
> I never did any manual inference for the moment so I am quite confused about 
> all this.
> Any help/resources pointing to the right direction would be greatly 
> appreciated.
> Thank you.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)