[jira] [Updated] (JENA-1549) Javadoc improvements for null-as-wildcard in SPI

[A. Soroka (JIRA)]

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

A. Soroka updated JENA-1549:

Component/s: Core

> Javadoc improvements for null-as-wildcard in SPI
> 
>
> Key: JENA-1549
> URL: https://issues.apache.org/jira/browse/JENA-1549
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Core
>Affects Versions: Jena 3.7.0
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Methods in the {{Triple/Graph/DatasetGraph}} SPI that accept null-as-wildcard 
> often don't mention or explain this in their Javadocs. It would be helpful if 
> they did.



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

[jira] [Created] (JENA-1549) Javadoc improvements for null-as-wildcard in SPI

[A. Soroka (JIRA)]

A. Soroka created JENA-1549:
---

 Summary: Javadoc improvements for null-as-wildcard in SPI
 Key: JENA-1549
 URL: https://issues.apache.org/jira/browse/JENA-1549
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Affects Versions: Jena 3.7.0
Reporter: A. Soroka
Assignee: A. Soroka


Methods in the {{Triple/Graph/DatasetGraph}} SPI that accept null-as-wildcard 
often don't mention or explain this in their Javadocs. It would be helpful if 
they did.



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

Re: parsing and matching triples

[Andy Seaborne]

On 12/05/18 17:26, Dave Reynolds wrote:

On 11/05/18 20:35, ajs6f wrote:


On May 9, 2018, at 3:31 AM, Dave Reynolds  
wrote:


On 08/05/18 16:55, ajs6f wrote:

Forking a thread off to dev@:
Do we have a global policy about where null is accepted as a 
wildcard? I know it works in at least some places...
I would love to (over an appropriate period of time and with lots of 
warnings and deprecation and so forth) stop letting it be a wildcard 
and require code to use the actual wildcard objects.


-1

We have a huge amount of code that assumes null-as-wildcard as 
provided for in the public RDF API and I doubt we're alone. There 
would no chance of porting all that through a normal deprecation cycle.


Fair enough, Dave. Just to be clear, are you saying as much as that 
new methods in the public API should always accept null-as-wildcard, 
or just that we oughtn't be changing extant methods now?


The latter. I've no particular attachment to null-as-wildcard as a 
design pattern so new APIs (at least ones which aren't just tweaks on 
the existing API) could go a different route.


I'm against having a mixed design in one API (e.g. new methods on Graph, 
or elsewhere in related classes/interfaces).  Design uniformity matters 
and the current SPI is what it is.


I believe that new API work should be matured separately. There is scope 
for more modern design, although with the existence of Commons RDF, it 
needs to find it's own rational and community.


Andy



Dave


On May 8, 2018, at 11:51 AM, Andy Seaborne  wrote:

Barry,

As a general concept "matching" happens at different levels.

Triple.match corresponds to the matching done by Graph.find - RDF 
terms (URI, bnode, literal) match exactly, and Node.ANY is a wildcard.


Triple t1 = Triple.ANY;
Triple t2 = SSE.parseTriple("(:s :p :o)");
t1.matches(t2) -> true
t2.matches(t1) -> false

Variables are a concept for SPARQL - and matches usefully need to 
return which variable matched which RDF Term.


Triple patterns match against graphs and return an iterator of ways 
they match.


Consider cases like "?x ?p ?x" where the variables impose am 
additional shape.


If you want variable bindings, you could build a SPARQL query or 
wrap up some of the internal code e.g.


/** Evaluate a triple pattern */
private static QueryIterator match(Graph source, Triple pattern) {
    ExecutionContext execContext =
  new ExecutionContext(ARQ.getContext(), source, null, null) ;
    QueryIterator chain = QueryIterRoot.create(execContext)
    chain = new QueryIterTriplePattern(chain, pattern, execContext) ;
    return chain ;
}

    Andy

On 08/05/18 09:21, Nouwt, B. (Barry) wrote:

Hi everybody,
I’m trying to reuse Apache Jena code that parses and matches 
triples. I’m currently looking at the SSE class’s parseTriple() 
method. This seems to fit my purpose for parsing a string 
representation of a triple into a triple object. I also noticed 
the following Javadoc on the Node.maches(Node) method:

Answer true iff this node accepts the other one as a match.
The default is an equality test; it is over-ridden in subclasses to
provide the appropriate semantics for literals, ANY, and variables.
Since this is exactly what I’m looking for, I’ve tried to match 
two triples using the matches() method, but it does not seem to work:

Triple t1 = SSE.parseTriple("(?s ?p ?o)");
Triple t2 = SSE.parseTriple("(test:subject test:predicate 
test:object)", pm);

t1.matches(t2)
The final statement returns false, while I would expect it to 
return true. Either, I’m missing something (which is completely 
realistic ), or I should use some other method to match two 
triples in the way described above.

Any help is appreciated!
Regards, Barry
This message may contain information that is not intended for you. 
If you are not the addressee or if this message was sent to you by 
mistake, you are requested to inform the sender and delete the 
message. TNO accepts no liability for the content of this e-mail, 
for the manner in which you use it and for damage of any kind 
resulting from the risks inherent to the electronic transmission 
of messages.

Re: parsing and matching triples

[ajs6f]

> On May 11, 2018, at 6:48 PM, Andy Seaborne  wrote:
> On 11/05/18 20:35, ajs6f wrote:
>>> On May 9, 2018, at 3:31 AM, Dave Reynolds  wrote:
>>> On 08/05/18 16:55, ajs6f wrote:
 Forking a thread off to dev@:
 Do we have a global policy about where null is accepted as a wildcard? I 
 know it works in at least some places...
> 
> You have mentioned one place - any others?

I don't understand-- it was you who mentioned the places it is accepted, not 
me. I just pointed out that for at least some of those places, it is not 
documented. Some places are worse, e.g. DatasetGraph:

/** Find matching quads in the dataset - may include wildcards, Node.ANY or null
* @see Graph#find(Triple)
*/
public Iterator find(Quad quad) ;

"wildcards, Node.ANY or null"? But Node.ANY and null _are_ the wildcards and 
they all behave the same way...?! The Javadocs for Graph just don't mention 
null as parameter at all.

I'm happy to make a PR for this-- I just want to make sure I have it straight 
myself. 

> The big pain with nulls is returned values leading to NPEs.
> That's not the case here, which is usage for arguments to functions/methods.

null _is_ a pain here. Accidentally passing a null reference into a method 
where it will be interpreted as wildcard can (e.g.) delete unexpected things or 
return a much larger query result than expected, _without any error_. That 
would be prevented by a null-object pattern. I understand that you may not have 
seen these problems, but I have. I'm not trying to argue that they deserve a 
solution that disrupts deployments (as Dave described) but that doesn't mean 
these kinds of problems don't exist.

>  This overlaps with the debate around Optional as argument.

No one is suggesting introducing Optional at all, or changing any return types, 
or removing null from the whole API or from Java (!). My question was pretty 
clear: are we keeping null-as-wildcard for the extant API, or requiring it for 
all new API, and Dave just answered it as I would: no, new API doesn't have to 
continue the pattern. I'll try to get in a PR for Graph/DatasetGraph Javadocs 
shortly.

ajs6f

> 
>   Andy
> 
> 
> 
>> ajs6f
>>> Dave
>>> 
> On May 8, 2018, at 11:51 AM, Andy Seaborne  wrote:
> 
> Barry,
> 
> As a general concept "matching" happens at different levels.
> 
> Triple.match corresponds to the matching done by Graph.find - RDF terms 
> (URI, bnode, literal) match exactly, and Node.ANY is a wildcard.
> 
> Triple t1 = Triple.ANY;
> Triple t2 = SSE.parseTriple("(:s :p :o)");
> t1.matches(t2) -> true
> t2.matches(t1) -> false
> 
> Variables are a concept for SPARQL - and matches usefully need to return 
> which variable matched which RDF Term.
> 
> Triple patterns match against graphs and return an iterator of ways they 
> match.
> 
> Consider cases like "?x ?p ?x" where the variables impose am additional 
> shape.
> 
> If you want variable bindings, you could build a SPARQL query or wrap up 
> some of the internal code e.g.
> 
> /** Evaluate a triple pattern */
> private static QueryIterator match(Graph source, Triple pattern) {
>ExecutionContext execContext =
>  new ExecutionContext(ARQ.getContext(), source, null, null) ;
>QueryIterator chain = QueryIterRoot.create(execContext)
>chain = new QueryIterTriplePattern(chain, pattern, execContext) ;
>return chain ;
> }
> 
>Andy
> 
> On 08/05/18 09:21, Nouwt, B. (Barry) wrote:
>> Hi everybody,
>> I’m trying to reuse Apache Jena code that parses and matches triples. 
>> I’m currently looking at the SSE class’s parseTriple() method. This 
>> seems to fit my purpose for parsing a string representation of a triple 
>> into a triple object. I also noticed the following Javadoc on the 
>> Node.maches(Node) method:
>> Answer true iff this node accepts the other one as a match.
>> The default is an equality test; it is over-ridden in subclasses to
>> provide the appropriate semantics for literals, ANY, and variables.
>> Since this is exactly what I’m looking for, I’ve tried to match two 
>> triples using the matches() method, but it does not seem to work:
>> Triple t1 = SSE.parseTriple("(?s ?p ?o)");
>> Triple t2 = SSE.parseTriple("(test:subject test:predicate test:object)", 
>> pm);
>> t1.matches(t2)
>> The final statement returns false, while I would expect it to return 
>> true. Either, I’m missing something (which is completely realistic ), 
>> or I should use some other method to match two triples in the way 
>> described above.
>> Any help is appreciated!
>> Regards, Barry
>> This message may contain information that is not intended for you. If 
>> you are not the addressee or if this message was sent to you by mistake, 

[GitHub] jena issue #421: Escape @xerces.internal annotations

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/421
  
Okay, either way works for me. This is already done, so easier!


---

Re: parsing and matching triples

[Dave Reynolds]

On 11/05/18 20:35, ajs6f wrote:



On May 9, 2018, at 3:31 AM, Dave Reynolds  wrote:

On 08/05/18 16:55, ajs6f wrote:

Forking a thread off to dev@:
Do we have a global policy about where null is accepted as a wildcard? I know 
it works in at least some places...
I would love to (over an appropriate period of time and with lots of warnings 
and deprecation and so forth) stop letting it be a wildcard and require code to 
use the actual wildcard objects.


-1

We have a huge amount of code that assumes null-as-wildcard as provided for in 
the public RDF API and I doubt we're alone. There would no chance of porting 
all that through a normal deprecation cycle.


Fair enough, Dave. Just to be clear, are you saying as much as that new methods 
in the public API should always accept null-as-wildcard, or just that we 
oughtn't be changing extant methods now?


The latter. I've no particular attachment to null-as-wildcard as a 
design pattern so new APIs (at least ones which aren't just tweaks on 
the existing API) could go a different route.


Dave


On May 8, 2018, at 11:51 AM, Andy Seaborne  wrote:

Barry,

As a general concept "matching" happens at different levels.

Triple.match corresponds to the matching done by Graph.find - RDF terms (URI, 
bnode, literal) match exactly, and Node.ANY is a wildcard.

Triple t1 = Triple.ANY;
Triple t2 = SSE.parseTriple("(:s :p :o)");
t1.matches(t2) -> true
t2.matches(t1) -> false

Variables are a concept for SPARQL - and matches usefully need to return which 
variable matched which RDF Term.

Triple patterns match against graphs and return an iterator of ways they match.

Consider cases like "?x ?p ?x" where the variables impose am additional shape.

If you want variable bindings, you could build a SPARQL query or wrap up some 
of the internal code e.g.

/** Evaluate a triple pattern */
private static QueryIterator match(Graph source, Triple pattern) {
ExecutionContext execContext =
  new ExecutionContext(ARQ.getContext(), source, null, null) ;
QueryIterator chain = QueryIterRoot.create(execContext)
chain = new QueryIterTriplePattern(chain, pattern, execContext) ;
return chain ;
}

Andy

On 08/05/18 09:21, Nouwt, B. (Barry) wrote:

Hi everybody,
I’m trying to reuse Apache Jena code that parses and matches triples. I’m 
currently looking at the SSE class’s parseTriple() method. This seems to fit my 
purpose for parsing a string representation of a triple into a triple object. I 
also noticed the following Javadoc on the Node.maches(Node) method:
Answer true iff this node accepts the other one as a match.
The default is an equality test; it is over-ridden in subclasses to
provide the appropriate semantics for literals, ANY, and variables.
Since this is exactly what I’m looking for, I’ve tried to match two triples 
using the matches() method, but it does not seem to work:
Triple t1 = SSE.parseTriple("(?s ?p ?o)");
Triple t2 = SSE.parseTriple("(test:subject test:predicate test:object)", pm);
t1.matches(t2)
The final statement returns false, while I would expect it to return true. 
Either, I’m missing something (which is completely realistic ), or I should 
use some other method to match two triples in the way described above.
Any help is appreciated!
Regards, Barry
This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.

[GitHub] jena issue #421: Escape @xerces.internal annotations

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/421
  
The PR leaves the code as much as-is by escaping the annotation in a 
`{@literal ...}`.  By making this reversible change, comparing to the original 
easier, if it is ever needed. We could remove it completely. It does not do 
anything.



---

Re: Old code.

[ajs6f]

https://jena.apache.org/download/maven.html shows jena-maven-tools with 
description "Maven Plugins, including schemagen", and as far as I can see, 
schemagen is the _only_ tool being made available in -maven-tools.

So, eyeball and -maven-tools are candidates for a "holding pen"? (From which of 
course things could be moved back to the released space if they get some love 
and attention.)

ajs6f

> On May 12, 2018, at 5:32 AM, Andy Seaborne  wrote:
> 
> schemagen is in jena-cmds
> 
> jena-maven-tools is a maven plugin.
> 
> (all this is in the codebase : "find" is your friend!)
> 
>   Andy
> 
> On 12/05/18 09:38, Claude Warren wrote:
>> Jena maven tools.  that does not include the schema gen does it or is that
>> a different maven tool?
>> On Sat, May 12, 2018 at 12:29 AM, Andy Seaborne  wrote:
>>> 
>>> 
>>> On 11/05/18 20:07, ajs6f wrote:
>>> 
 Not to hijack the thread,
 
>>> 
>>> (new thread? or at least change the subject?)
>>> 
>>> but I think a natural question is: do we have any other such examples
 (well-defined portions of code that aren't under any real maintenance and
 that we are not releasing)?
 
>>> 
>>> All the code is available for inspection as is the documentation so it
>>> would be useful to check that.
>>> 
>>> 
>>> One I know of:
>>> 
>>> jena-maven-tools/ isn't currently being built because it it breaks with
>>> the latest Apache parent (not the first time this has happened).
>>> 
>>> Andy
>>> 

[jira] [Resolved] (JENA-1547) Fix TDB2 metadata

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1547.
-
Resolution: Fixed

> Fix TDB2 metadata
> -
>
> Key: JENA-1547
> URL: https://issues.apache.org/jira/browse/JENA-1547
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> TDB2 metadata is a copy from TDB1.
> This causes a split package "org.apache.jena.tdb" due to the resource file.
> The metadata handling in class TDB2 needs moving to "tdb2".



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

[jira] [Assigned] (JENA-1545) Add ParserProfileWrapper

[Andy Seaborne (JIRA)]

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

Andy Seaborne reassigned JENA-1545:
---

Assignee: Andy Seaborne

> Add ParserProfileWrapper
> 
>
> Key: JENA-1545
> URL: https://issues.apache.org/jira/browse/JENA-1545
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> See [https://github.com/apache/jena/pull/299]
>  



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

[jira] [Resolved] (JENA-1548) Pass a custom NodeFormatter to TurtleShell

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1548.
-
Resolution: Fixed

> Pass a custom NodeFormatter to TurtleShell 
> ---
>
> Key: JENA-1548
> URL: https://issues.apache.org/jira/browse/JENA-1548
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> PR https://github.com/apache/jena/pull/418
> contributed by Olaf Hartig.
> See
> https://github.com/apache/jena/pull/299#issuecomment-387011857



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

[jira] [Resolved] (JENA-1544) FROM handling is inconsistent

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1544.
-
Resolution: Fixed

> FROM handling is inconsistent
> -
>
> Key: JENA-1544
> URL: https://issues.apache.org/jira/browse/JENA-1544
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> Dataset description (FROM and FROM NAMED) handling seems to be missing for 
> memory datasets.
> For persistent ones, the action is to take graph from the dataset itself.
> The proposal is to add this for memory datasets.
> The ability to load graphs from the web or from files using FROM / FROM NAMED 
> will be available when a query is executed with no dataset.
> Executing a query with no dataset and no dataset description is an error.



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

[jira] [Resolved] (JENA-1545) Add ParserProfileWrapper

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1545.
-
   Resolution: Fixed
Fix Version/s: Jena 3.8.0

> Add ParserProfileWrapper
> 
>
> Key: JENA-1545
> URL: https://issues.apache.org/jira/browse/JENA-1545
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> See [https://github.com/apache/jena/pull/299]
>  



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

[jira] [Commented] (JENA-1548) Pass a custom NodeFormatter to TurtleShell

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1548: Merge commit 'refs/pull/418/head' of https://github.com/apache/jena

This closes #418.


> Pass a custom NodeFormatter to TurtleShell 
> ---
>
> Key: JENA-1548
> URL: https://issues.apache.org/jira/browse/JENA-1548
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> PR https://github.com/apache/jena/pull/418
> contributed by Olaf Hartig.
> See
> https://github.com/apache/jena/pull/299#issuecomment-387011857



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

[jira] [Commented] (JENA-1547) Fix TDB2 metadata

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1547: Metadata for TDB2


> Fix TDB2 metadata
> -
>
> Key: JENA-1547
> URL: https://issues.apache.org/jira/browse/JENA-1547
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> TDB2 metadata is a copy from TDB1.
> This causes a split package "org.apache.jena.tdb" due to the resource file.
> The metadata handling in class TDB2 needs moving to "tdb2".



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

[jira] [Commented] (JENA-1544) FROM handling is inconsistent

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1544: Consistent FROM/FROM NAMED naming handling


> FROM handling is inconsistent
> -
>
> Key: JENA-1544
> URL: https://issues.apache.org/jira/browse/JENA-1544
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> Dataset description (FROM and FROM NAMED) handling seems to be missing for 
> memory datasets.
> For persistent ones, the action is to take graph from the dataset itself.
> The proposal is to add this for memory datasets.
> The ability to load graphs from the web or from files using FROM / FROM NAMED 
> will be available when a query is executed with no dataset.
> Executing a query with no dataset and no dataset description is an error.



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

[jira] [Commented] (JENA-1545) Add ParserProfileWrapper

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1545: Merge commit 'refs/pull/416/head' of https://github.com/apache/jena

This closes #416.


> Add ParserProfileWrapper
> 
>
> Key: JENA-1545
> URL: https://issues.apache.org/jira/browse/JENA-1545
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Priority: Major
>
> See [https://github.com/apache/jena/pull/299]
>  



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

[jira] [Commented] (JENA-1547) Fix TDB2 metadata

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1547: Merge commit 'refs/pull/420/head' of https://github.com/apache/jena

This closes #420.


> Fix TDB2 metadata
> -
>
> Key: JENA-1547
> URL: https://issues.apache.org/jira/browse/JENA-1547
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> TDB2 metadata is a copy from TDB1.
> This causes a split package "org.apache.jena.tdb" due to the resource file.
> The metadata handling in class TDB2 needs moving to "tdb2".



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

[jira] [Commented] (JENA-1547) Fix TDB2 metadata

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1547:
--

Github user asfgit closed the pull request at:

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


> Fix TDB2 metadata
> -
>
> Key: JENA-1547
> URL: https://issues.apache.org/jira/browse/JENA-1547
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> TDB2 metadata is a copy from TDB1.
> This causes a split package "org.apache.jena.tdb" due to the resource file.
> The metadata handling in class TDB2 needs moving to "tdb2".



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

[jira] [Commented] (JENA-1545) Add ParserProfileWrapper

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1545: ParserProfileWrapper


> Add ParserProfileWrapper
> 
>
> Key: JENA-1545
> URL: https://issues.apache.org/jira/browse/JENA-1545
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Priority: Major
>
> See [https://github.com/apache/jena/pull/299]
>  



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

[jira] [Commented] (JENA-1545) Add ParserProfileWrapper

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1545:
--

Github user asfgit closed the pull request at:

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


> Add ParserProfileWrapper
> 
>
> Key: JENA-1545
> URL: https://issues.apache.org/jira/browse/JENA-1545
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Priority: Major
>
> See [https://github.com/apache/jena/pull/299]
>  



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

[jira] [Commented] (JENA-1544) FROM handling is inconsistent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1544:
--

Github user asfgit closed the pull request at:

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


> FROM handling is inconsistent
> -
>
> Key: JENA-1544
> URL: https://issues.apache.org/jira/browse/JENA-1544
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> Dataset description (FROM and FROM NAMED) handling seems to be missing for 
> memory datasets.
> For persistent ones, the action is to take graph from the dataset itself.
> The proposal is to add this for memory datasets.
> The ability to load graphs from the web or from files using FROM / FROM NAMED 
> will be available when a query is executed with no dataset.
> Executing a query with no dataset and no dataset description is an error.



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

[GitHub] jena pull request #420: JENA-1547: Metadata for TDB2

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena pull request #416: JENA-1545: ParserProfileWrapper

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena pull request #418: pass a custom NodeFormatter to TurtleShell

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena pull request #417: JENA-1544: Consistent FROM/FROM NAMED naming handlin...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jena issue #421: Escape @xerces.internal annotations

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/421
  
I've never seen `@xerces.internal` before, but it seems to denote types 
internal to Xerces, right? My one question is: do we need to keep it on all 
types or can we stick it on a package comment? (Since we're not planning on 
maintaining a separate "branch" of Xerces as a whole.)


---

[jira] [Created] (JENA-1548) Pass a custom NodeFormatter to TurtleShell

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1548:
---

 Summary: Pass a custom NodeFormatter to TurtleShell 
 Key: JENA-1548
 URL: https://issues.apache.org/jira/browse/JENA-1548
 Project: Apache Jena
  Issue Type: Improvement
  Components: RIOT
Affects Versions: Jena 3.8.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.8.0


PR https://github.com/apache/jena/pull/418
contributed by Olaf Hartig.

See
https://github.com/apache/jena/pull/299#issuecomment-387011857



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

[GitHub] jena pull request #421: Escape @xerces.internal annotations

[afs]

GitHub user afs opened a pull request:

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

Escape @xerces.internal annotations

Replace "@xerces.internal" with "{@literal @xerces.internal}".

This suppresses javadoc warning about unknown javadoc tags.


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

$ git pull https://github.com/afs/jena more-javadoc

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

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


commit dd5f4f4d58d85b7f43a5dfd7867376fec0fbc0dd
Author: Andy Seaborne 
Date:   2018-05-12T15:51:37Z

Escape @xerces.internal annotations




---

[jira] [Commented] (JENA-1547) Fix TDB2 metadata

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1547:
--

GitHub user afs opened a pull request:

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

JENA-1547: Metadata for TDB2



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

$ git pull https://github.com/afs/jena tdb2-meta

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

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


commit dee610e5c08c3b59bdbaebdbaa35bc0ed38ba0c7
Author: Andy Seaborne 
Date:   2018-05-12T09:54:12Z

JENA-1547: Metadata for TDB2




> Fix TDB2 metadata
> -
>
> Key: JENA-1547
> URL: https://issues.apache.org/jira/browse/JENA-1547
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> TDB2 metadata is a copy from TDB1.
> This causes a split package "org.apache.jena.tdb" due to the resource file.
> The metadata handling in class TDB2 needs moving to "tdb2".



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

[GitHub] jena pull request #420: JENA-1547: Metadata for TDB2

[afs]

GitHub user afs opened a pull request:

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

JENA-1547: Metadata for TDB2



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

$ git pull https://github.com/afs/jena tdb2-meta

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

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


commit dee610e5c08c3b59bdbaebdbaa35bc0ed38ba0c7
Author: Andy Seaborne 
Date:   2018-05-12T09:54:12Z

JENA-1547: Metadata for TDB2




---

[jira] [Created] (JENA-1547) Fix TDB2 metadata

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1547:
---

 Summary: Fix TDB2 metadata
 Key: JENA-1547
 URL: https://issues.apache.org/jira/browse/JENA-1547
 Project: Apache Jena
  Issue Type: Bug
  Components: TDB2
Affects Versions: Jena 3.7.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.8.0


TDB2 metadata is a copy from TDB1.

This causes a split package "org.apache.jena.tdb" due to the resource file.

The metadata handling in class TDB2 needs moving to "tdb2".




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

Re: Old code.

[Claude Warren]

Jena maven tools.  that does not include the schema gen does it or is that
a different maven tool?

On Sat, May 12, 2018 at 12:29 AM, Andy Seaborne  wrote:

>
>
> On 11/05/18 20:07, ajs6f wrote:
>
>> Not to hijack the thread,
>>
>
> (new thread? or at least change the subject?)
>
> but I think a natural question is: do we have any other such examples
>> (well-defined portions of code that aren't under any real maintenance and
>> that we are not releasing)?
>>
>
> All the code is available for inspection as is the documentation so it
> would be useful to check that.
>
>
> One I know of:
>
> jena-maven-tools/ isn't currently being built because it it breaks with
> the latest Apache parent (not the first time this has happened).
>
> Andy
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren