[jira] [Resolved] (JENA-1583) BigDecimal literal created but not handled by Utils
[ https://issues.apache.org/jira/browse/JENA-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1583. - Resolution: Fixed Fix Version/s: Jena 3.9.0 > BigDecimal literal created but not handled by Utils > --- > > Key: JENA-1583 > URL: https://issues.apache.org/jira/browse/JENA-1583 > Project: Apache Jena > Issue Type: Bug > Components: Core >Affects Versions: Jena 3.0.0 >Reporter: Andrew Crapo >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.9.0 > > > If a Literal of type xsd:decimal is created the value is a BigDecimal. > However, if such a Literal is passed into the com.ge.research.jena.Utils > compareTypedLiterals method, the value is only checked for Float and Double > so it defaults to being treated as Long, which can give erroneous results. I > checked the current code base on github.com and this appears to still be an > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1583) BigDecimal literal created but not handled by Utils
[ https://issues.apache.org/jira/browse/JENA-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569507#comment-16569507 ] ASF subversion and git services commented on JENA-1583: --- Commit 93bab17bbf8073fe0d7cf566411aed3da6b34cc3 in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=93bab17 ] JENA-1583: Merge commit 'refs/pull/454/head' of https://github.com/apache/jena This closes #454. > BigDecimal literal created but not handled by Utils > --- > > Key: JENA-1583 > URL: https://issues.apache.org/jira/browse/JENA-1583 > Project: Apache Jena > Issue Type: Bug > Components: Core >Affects Versions: Jena 3.0.0 >Reporter: Andrew Crapo >Assignee: Andy Seaborne >Priority: Major > > If a Literal of type xsd:decimal is created the value is a BigDecimal. > However, if such a Literal is passed into the com.ge.research.jena.Utils > compareTypedLiterals method, the value is only checked for Float and Double > so it defaults to being treated as Long, which can give erroneous results. I > checked the current code base on github.com and this appears to still be an > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1583) BigDecimal literal created but not handled by Utils
[ https://issues.apache.org/jira/browse/JENA-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569508#comment-16569508 ] ASF GitHub Bot commented on JENA-1583: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/454 > BigDecimal literal created but not handled by Utils > --- > > Key: JENA-1583 > URL: https://issues.apache.org/jira/browse/JENA-1583 > Project: Apache Jena > Issue Type: Bug > Components: Core >Affects Versions: Jena 3.0.0 >Reporter: Andrew Crapo >Assignee: Andy Seaborne >Priority: Major > > If a Literal of type xsd:decimal is created the value is a BigDecimal. > However, if such a Literal is passed into the com.ge.research.jena.Utils > compareTypedLiterals method, the value is only checked for Float and Double > so it defaults to being treated as Long, which can give erroneous results. I > checked the current code base on github.com and this appears to still be an > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1583) BigDecimal literal created but not handled by Utils
[ https://issues.apache.org/jira/browse/JENA-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569506#comment-16569506 ] ASF subversion and git services commented on JENA-1583: --- Commit 71acf2c534711527d4d4b0b55f9a584de492c791 in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=71acf2c ] JENA-1583: Rule system: Util.compare > BigDecimal literal created but not handled by Utils > --- > > Key: JENA-1583 > URL: https://issues.apache.org/jira/browse/JENA-1583 > Project: Apache Jena > Issue Type: Bug > Components: Core >Affects Versions: Jena 3.0.0 >Reporter: Andrew Crapo >Assignee: Andy Seaborne >Priority: Major > > If a Literal of type xsd:decimal is created the value is a BigDecimal. > However, if such a Literal is passed into the com.ge.research.jena.Utils > compareTypedLiterals method, the value is only checked for Float and Double > so it defaults to being treated as Long, which can give erroneous results. I > checked the current code base on github.com and this appears to still be an > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #454: JENA-1583: Rule system: Util.compare
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/454 ---
[jira] [Assigned] (JENA-1583) BigDecimal literal created but not handled by Utils
[ https://issues.apache.org/jira/browse/JENA-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne reassigned JENA-1583: --- Assignee: Andy Seaborne > BigDecimal literal created but not handled by Utils > --- > > Key: JENA-1583 > URL: https://issues.apache.org/jira/browse/JENA-1583 > Project: Apache Jena > Issue Type: Bug > Components: Core >Affects Versions: Jena 3.0.0 >Reporter: Andrew Crapo >Assignee: Andy Seaborne >Priority: Major > > If a Literal of type xsd:decimal is created the value is a BigDecimal. > However, if such a Literal is passed into the com.ge.research.jena.Utils > compareTypedLiterals method, the value is only checked for Float and Double > so it defaults to being treated as Long, which can give erroneous results. I > checked the current code base on github.com and this appears to still be an > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString
[ https://issues.apache.org/jira/browse/JENA-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569502#comment-16569502 ] Andy Seaborne commented on JENA-1578: - Merged - thanks! > SPARQL VALUES for ParameterizedSparqlString > --- > > Key: JENA-1578 > URL: https://issues.apache.org/jira/browse/JENA-1578 > Project: Apache Jena > Issue Type: New Feature > Components: ARQ >Affects Versions: Jena 3.8.0 >Reporter: Greg Albiston >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > ParameterizedSparqlString provides an API for substituting variables within > SPARQL queries with bound values. It does not support the SPARQL VALUES > keyword which allows multiple values to be specified. The VALUES syntax > supports multiple values for a single variable, sets of values for multiple > variables and multiple sets of values for multiple values. > Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString
[ https://issues.apache.org/jira/browse/JENA-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1578. - Resolution: Implemented Assignee: Andy Seaborne Fix Version/s: Jena 3.9.0 > SPARQL VALUES for ParameterizedSparqlString > --- > > Key: JENA-1578 > URL: https://issues.apache.org/jira/browse/JENA-1578 > Project: Apache Jena > Issue Type: New Feature > Components: ARQ >Affects Versions: Jena 3.8.0 >Reporter: Greg Albiston >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > ParameterizedSparqlString provides an API for substituting variables within > SPARQL queries with bound values. It does not support the SPARQL VALUES > keyword which allows multiple values to be specified. The VALUES syntax > supports multiple values for a single variable, sets of values for multiple > variables and multiple sets of values for multiple values. > Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString
[ https://issues.apache.org/jira/browse/JENA-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569501#comment-16569501 ] ASF GitHub Bot commented on JENA-1578: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/449 > SPARQL VALUES for ParameterizedSparqlString > --- > > Key: JENA-1578 > URL: https://issues.apache.org/jira/browse/JENA-1578 > Project: Apache Jena > Issue Type: New Feature > Components: ARQ >Affects Versions: Jena 3.8.0 >Reporter: Greg Albiston >Priority: Minor > > ParameterizedSparqlString provides an API for substituting variables within > SPARQL queries with bound values. It does not support the SPARQL VALUES > keyword which allows multiple values to be specified. The VALUES syntax > supports multiple values for a single variable, sets of values for multiple > variables and multiple sets of values for multiple values. > Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #449: JENA-1578
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/449 ---
[jira] [Commented] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString
[ https://issues.apache.org/jira/browse/JENA-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569500#comment-16569500 ] ASF subversion and git services commented on JENA-1578: --- Commit 43feda68f0b781cacb7a85333e07c5c3c3c22f68 in jena's branch refs/heads/master from [~an...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=43feda6 ] JENA-1578: Merge commit 'refs/pull/449/head' of https://github.com/apache/jena This closes #449. > SPARQL VALUES for ParameterizedSparqlString > --- > > Key: JENA-1578 > URL: https://issues.apache.org/jira/browse/JENA-1578 > Project: Apache Jena > Issue Type: New Feature > Components: ARQ >Affects Versions: Jena 3.8.0 >Reporter: Greg Albiston >Priority: Minor > > ParameterizedSparqlString provides an API for substituting variables within > SPARQL queries with bound values. It does not support the SPARQL VALUES > keyword which allows multiple values to be specified. The VALUES syntax > supports multiple values for a single variable, sets of values for multiple > variables and multiple sets of values for multiple values. > Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569487#comment-16569487
]
ASF GitHub Bot commented on JENA-1584:
--
Github user afs commented on the issue:
https://github.com/apache/jena/pull/455
Great test, thanks!
It will register itself:
Lang lang = TurtleJavaccReaderRIOT.lang;
TurtleJavaccReaderRIOT.register();
RDFParser.create().forceLang(lang).source(FILE).build()
.parse(StreamRDFLib.writer(System.out));
It has a won't-clash MIME type ("text/turtle-jcc") and file extension
("ttljcc") even though it is not really for general use. `forceLang` cause the
parser to always use the `lang` whatever the FILE may say.
> Include a Javacc based Turtle parser in RIOT
>
>
> Key: JENA-1584
> URL: https://issues.apache.org/jira/browse/JENA-1584
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> Turtle is the basis for some additional languages (RDF*, SHACL and ShEX
> compact forms).
> The main RIOT Turtle parser is written for speed, with the tuned tokenizer
> and directly written java grammar parser. This makes it harder to reuse and
> extend.
> This ticket proposes including another RDF 1.1 compliant Turtle parser based
> on JavaCC to provide an easier route for additional languages by providing
> all the details of Turtle such as the tokens and prefix name handling, in a
> form more suitable as a base for the new language. It will still be by being
> a copy of the parser, system, not class inheritance.)
> RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
> tokens and several grammar rules.
> This would not be active by default (i.e. not a registered {{Lang}} and it's
> parser factory but registered by automatic initialization). It's test suite
> would be run in the build and pass the RDF 1.1 Turtle test suite.
>
> There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
> pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that
> read turtle files. It could be moved into the test area except there appear
> to be some legacy applications that only use jena-core.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569467#comment-16569467
]
ASF GitHub Bot commented on JENA-1584:
--
Github user kinow commented on the issue:
https://github.com/apache/jena/pull/455
Tested just the new parser with with the following code:
```java
public static void main(String args[]) {
try {
java.io.Reader in = new
java.io.StringReader(FileUtils.readFileToString(new
File("/home/kinow/Development/php/workspace/Skosmos/config.ttl"),
Charset.forName("UTF-8"))) ;
TurtleJavacc parser = new TurtleJavacc(in) ;
FactoryRDF factory = new FactoryRDFStd();
ErrorHandler errorHandler =
ErrorHandlerFactory.errorHandlerSimple();
IRIResolver resolver = IRIResolver.create();
PrefixMap prefixMap = new PrefixMapStd();
Context context = null;
boolean checking = true ;
boolean strictMode = true;
ParserProfile profile = new ParserProfileStd(factory,
errorHandler, resolver, prefixMap, context, checking, strictMode);
StreamRDF dest = new PrintingStreamRDF(System.out);
parser.setDest(dest);
parser.setProfile(profile);
dest.start();
parser.parse();
dest.finish();
System.out.println("Parsed query successfully!") ;
System.out.println("---" + System.lineSeparator()) ;
} catch (Exception e) {
System.out.println("Parser error: " + e.getMessage()) ;
e.printStackTrace(System.err) ;
}
}
```
`config.ttl` is the config file for Skosmos. The template can be found
[here](https://github.com/NatLibFi/Skosmos/blob/c68a9715ced03c17906299f421fe97b27047566c/config.ttl.dist).
Code worked with no issues, and for what's worth, here's the output:
```shell
log4j:WARN No appenders could be found for logger
(org.apache.jena.util.FileManager).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
PREFIX void:
PREFIX rdf:
PREFIX rdfs:
PREFIX owl:
PREFIX xsd:
PREFIX dc:
PREFIX sd:
PREFIX skos:
PREFIX skosmos:
PREFIX isothes:
PREFIX mdrtype:
.
"http://fuseki:3030/skosmos/sparql; .
"Generic" .
"false"^^ .
"60"^^ .
"60"^^ .
"Skosmos" .
"http://localhost:8000/; .
??1 "fi" .
??1 "fi_FI.utf8" .
??0 ??1 .
??0 ??2 .
??3 "sv" .
??3 "sv_SE.utf8" .
??2 ??3 .
??2 ??4 .
??5 "en" .
??5 "en_GB.utf8" .
??4 ??5 .
??4
.
??0 .
"20"^^ .
"1000"^^ .
[GitHub] jena issue #455: JENA-1584: A Javacc Turtle parser for reference.
Github user kinow commented on the issue:
https://github.com/apache/jena/pull/455
Tested just the new parser with with the following code:
```java
public static void main(String args[]) {
try {
java.io.Reader in = new
java.io.StringReader(FileUtils.readFileToString(new
File("/home/kinow/Development/php/workspace/Skosmos/config.ttl"),
Charset.forName("UTF-8"))) ;
TurtleJavacc parser = new TurtleJavacc(in) ;
FactoryRDF factory = new FactoryRDFStd();
ErrorHandler errorHandler =
ErrorHandlerFactory.errorHandlerSimple();
IRIResolver resolver = IRIResolver.create();
PrefixMap prefixMap = new PrefixMapStd();
Context context = null;
boolean checking = true ;
boolean strictMode = true;
ParserProfile profile = new ParserProfileStd(factory,
errorHandler, resolver, prefixMap, context, checking, strictMode);
StreamRDF dest = new PrintingStreamRDF(System.out);
parser.setDest(dest);
parser.setProfile(profile);
dest.start();
parser.parse();
dest.finish();
System.out.println("Parsed query successfully!") ;
System.out.println("---" + System.lineSeparator()) ;
} catch (Exception e) {
System.out.println("Parser error: " + e.getMessage()) ;
e.printStackTrace(System.err) ;
}
}
```
`config.ttl` is the config file for Skosmos. The template can be found
[here](https://github.com/NatLibFi/Skosmos/blob/c68a9715ced03c17906299f421fe97b27047566c/config.ttl.dist).
Code worked with no issues, and for what's worth, here's the output:
```shell
log4j:WARN No appenders could be found for logger
(org.apache.jena.util.FileManager).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
PREFIX void:
PREFIX rdf:
PREFIX rdfs:
PREFIX owl:
PREFIX xsd:
PREFIX dc:
PREFIX sd:
PREFIX skos:
PREFIX skosmos:
PREFIX isothes:
PREFIX mdrtype:
.
"http://fuseki:3030/skosmos/sparql; .
"Generic" .
"false"^^ .
"60"^^ .
"60"^^ .
"Skosmos" .
"http://localhost:8000/; .
??1 "fi" .
??1 "fi_FI.utf8" .
??0 ??1 .
??0 ??2 .
??3 "sv" .
??3 "sv_SE.utf8" .
??2 ??3 .
??2 ??4 .
??5 "en" .
??5 "en_GB.utf8" .
??4 ??5 .
??4
.
??0 .
"20"^^ .
"1000"^^ .
"true"^^ .
"false"^^ .
"/tmp/skosmos.log" .
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569463#comment-16569463
]
ASF GitHub Bot commented on JENA-1584:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735246
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/TokenMgrError.java
---
@@ -0,0 +1,165 @@
+/* Generated By:JavaCC: Do not edit this line. TokenMgrError.java Version
6.0 */
+/* JavaCCOptions: */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/** Token Manager Error. */
+public class TokenMgrError extends Error
+{
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /*
+ * Ordinals for various reasons why an Error of this type can be thrown.
+ */
+
+ /**
+ * Lexical error occurred.
+ */
+ static final int LEXICAL_ERROR = 0;
+
+ /**
+ * An attempt was made to create a second instance of a static token
manager.
+ */
+ static final int STATIC_LEXER_ERROR = 1;
+
+ /**
+ * Tried to change to an invalid lexical state.
+ */
+ static final int INVALID_LEXICAL_STATE = 2;
+
+ /**
+ * Detected (and bailed out of) an infinite loop in the token manager.
+ */
+ static final int LOOP_DETECTED = 3;
+
+ /**
+ * Indicates the reason why the exception is thrown. It will have
+ * one of the above 4 values.
+ */
+ int errorCode;
+
+ /**
+ * Replaces unprintable characters by their escaped (or unicode escaped)
+ * equivalents in the given string
+ */
+ protected static final String addEscapes(String str) {
+StringBuffer retval = new StringBuffer();
--- End diff --
See comment above about `StringBuffer` / `StringBuilder`
> Include a Javacc based Turtle parser in RIOT
>
>
> Key: JENA-1584
> URL: https://issues.apache.org/jira/browse/JENA-1584
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> Turtle is the basis for some additional languages (RDF*, SHACL and ShEX
> compact forms).
> The main RIOT Turtle parser is written for speed, with the tuned tokenizer
> and directly written java grammar parser. This makes it harder to reuse and
> extend.
> This ticket proposes including another RDF 1.1 compliant Turtle parser based
> on JavaCC to provide an easier route for additional languages by providing
> all the details of Turtle such as the tokens and prefix name handling, in a
> form more suitable as a base for the new language. It will still be by being
> a copy of the parser, system, not class inheritance.)
> RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
> tokens and several grammar rules.
> This would not be active by default (i.e. not a registered {{Lang}} and it's
> parser factory but registered by automatic initialization). It's test suite
> would be run in the build and pass the RDF 1.1 Turtle test suite.
>
> There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
> pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that
> read turtle files. It could be moved into the test area except there appear
> to be some legacy applications that only use jena-core.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569464#comment-16569464
]
ASF GitHub Bot commented on JENA-1584:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735233
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/ParseException.java
---
@@ -0,0 +1,205 @@
+/* Generated By:JavaCC: Do not edit this line. ParseException.java Version
6.0 */
+/* JavaCCOptions:KEEP_LINE_COL=null */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/**
+ * This exception is thrown when parse errors are encountered.
+ * You can explicitly create objects of this exception type by
+ * calling the method generateParseException in the generated
+ * parser.
+ *
+ * You can modify this class to customize your error reporting
+ * mechanisms so long as you retain the public fields.
+ */
+public class ParseException extends Exception {
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /**
+ * This constructor is used by the method "generateParseException"
+ * in the generated parser. Calling this constructor generates
+ * a new object of this type with the fields "currentToken",
+ * "expectedTokenSequences", and "tokenImage" set.
+ */
+ public ParseException(Token currentTokenVal,
+int[][] expectedTokenSequencesVal,
+String[] tokenImageVal
+ )
+ {
+super(initialise(currentTokenVal, expectedTokenSequencesVal,
tokenImageVal));
+currentToken = currentTokenVal;
+expectedTokenSequences = expectedTokenSequencesVal;
+tokenImage = tokenImageVal;
+ }
+
+ /**
+ * The following constructors are for use by you for whatever
+ * purpose you can think of. Constructing the exception in this
+ * manner makes the exception behave in the normal way - i.e., as
+ * documented in the class "Throwable". The fields "errorToken",
+ * "expectedTokenSequences", and "tokenImage" do not contain
+ * relevant information. The JavaCC generated code does not use
+ * these constructors.
+ */
+
+ public ParseException() {
+super();
+ }
+
+ /** Constructor with message. */
+ public ParseException(String message) {
+super(message);
+ }
+
+
+ /**
+ * This is the last token that has been consumed successfully. If
+ * this object has been created due to a parse error, the token
+ * followng this token will (therefore) be the first error token.
+ */
+ public Token currentToken;
+
+ /**
+ * Each entry in this array is an array of integers. Each array
+ * of integers represents a sequence of tokens (by their ordinal
+ * values) that is expected at this point of the parse.
+ */
+ public int[][] expectedTokenSequences;
+
+ /**
+ * This is a reference to the "tokenImage" array of the generated
+ * parser within which the parse error occurred. This array is
+ * defined in the generated ...Constants interface.
+ */
+ public String[] tokenImage;
+
+ /**
+ * It uses "currentToken" and "expectedTokenSequences" to generate a
parse
+ * error message and returns it. If this object has been created
+ * due to a parse error, and you do not catch it (it gets thrown
+ * from the parser) the correct error message
+ * gets displayed.
+ */
+ private static String initialise(Token currentToken,
+ int[][] expectedTokenSequences,
+ String[] tokenImage) {
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569465#comment-16569465
]
ASF GitHub Bot commented on JENA-1584:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735228
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/ParseException.java
---
@@ -0,0 +1,205 @@
+/* Generated By:JavaCC: Do not edit this line. ParseException.java Version
6.0 */
+/* JavaCCOptions:KEEP_LINE_COL=null */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/**
+ * This exception is thrown when parse errors are encountered.
+ * You can explicitly create objects of this exception type by
+ * calling the method generateParseException in the generated
+ * parser.
+ *
+ * You can modify this class to customize your error reporting
+ * mechanisms so long as you retain the public fields.
+ */
+public class ParseException extends Exception {
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /**
+ * This constructor is used by the method "generateParseException"
+ * in the generated parser. Calling this constructor generates
+ * a new object of this type with the fields "currentToken",
+ * "expectedTokenSequences", and "tokenImage" set.
+ */
+ public ParseException(Token currentTokenVal,
+int[][] expectedTokenSequencesVal,
+String[] tokenImageVal
+ )
+ {
+super(initialise(currentTokenVal, expectedTokenSequencesVal,
tokenImageVal));
+currentToken = currentTokenVal;
+expectedTokenSequences = expectedTokenSequencesVal;
+tokenImage = tokenImageVal;
+ }
+
+ /**
+ * The following constructors are for use by you for whatever
+ * purpose you can think of. Constructing the exception in this
+ * manner makes the exception behave in the normal way - i.e., as
+ * documented in the class "Throwable". The fields "errorToken",
+ * "expectedTokenSequences", and "tokenImage" do not contain
+ * relevant information. The JavaCC generated code does not use
+ * these constructors.
+ */
+
+ public ParseException() {
+super();
+ }
+
+ /** Constructor with message. */
+ public ParseException(String message) {
+super(message);
+ }
+
+
+ /**
+ * This is the last token that has been consumed successfully. If
+ * this object has been created due to a parse error, the token
+ * followng this token will (therefore) be the first error token.
+ */
+ public Token currentToken;
+
+ /**
+ * Each entry in this array is an array of integers. Each array
+ * of integers represents a sequence of tokens (by their ordinal
+ * values) that is expected at this point of the parse.
+ */
+ public int[][] expectedTokenSequences;
+
+ /**
+ * This is a reference to the "tokenImage" array of the generated
+ * parser within which the parse error occurred. This array is
+ * defined in the generated ...Constants interface.
+ */
+ public String[] tokenImage;
+
+ /**
+ * It uses "currentToken" and "expectedTokenSequences" to generate a
parse
+ * error message and returns it. If this object has been created
+ * due to a parse error, and you do not catch it (it gets thrown
+ * from the parser) the correct error message
+ * gets displayed.
+ */
+ private static String initialise(Token currentToken,
+ int[][] expectedTokenSequences,
+ String[] tokenImage) {
[GitHub] jena pull request #455: JENA-1584: A Javacc Turtle parser for reference.
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735246
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/TokenMgrError.java
---
@@ -0,0 +1,165 @@
+/* Generated By:JavaCC: Do not edit this line. TokenMgrError.java Version
6.0 */
+/* JavaCCOptions: */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/** Token Manager Error. */
+public class TokenMgrError extends Error
+{
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /*
+ * Ordinals for various reasons why an Error of this type can be thrown.
+ */
+
+ /**
+ * Lexical error occurred.
+ */
+ static final int LEXICAL_ERROR = 0;
+
+ /**
+ * An attempt was made to create a second instance of a static token
manager.
+ */
+ static final int STATIC_LEXER_ERROR = 1;
+
+ /**
+ * Tried to change to an invalid lexical state.
+ */
+ static final int INVALID_LEXICAL_STATE = 2;
+
+ /**
+ * Detected (and bailed out of) an infinite loop in the token manager.
+ */
+ static final int LOOP_DETECTED = 3;
+
+ /**
+ * Indicates the reason why the exception is thrown. It will have
+ * one of the above 4 values.
+ */
+ int errorCode;
+
+ /**
+ * Replaces unprintable characters by their escaped (or unicode escaped)
+ * equivalents in the given string
+ */
+ protected static final String addEscapes(String str) {
+StringBuffer retval = new StringBuffer();
--- End diff --
See comment above about `StringBuffer` / `StringBuilder`
---
[GitHub] jena pull request #455: JENA-1584: A Javacc Turtle parser for reference.
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735233
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/ParseException.java
---
@@ -0,0 +1,205 @@
+/* Generated By:JavaCC: Do not edit this line. ParseException.java Version
6.0 */
+/* JavaCCOptions:KEEP_LINE_COL=null */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/**
+ * This exception is thrown when parse errors are encountered.
+ * You can explicitly create objects of this exception type by
+ * calling the method generateParseException in the generated
+ * parser.
+ *
+ * You can modify this class to customize your error reporting
+ * mechanisms so long as you retain the public fields.
+ */
+public class ParseException extends Exception {
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /**
+ * This constructor is used by the method "generateParseException"
+ * in the generated parser. Calling this constructor generates
+ * a new object of this type with the fields "currentToken",
+ * "expectedTokenSequences", and "tokenImage" set.
+ */
+ public ParseException(Token currentTokenVal,
+int[][] expectedTokenSequencesVal,
+String[] tokenImageVal
+ )
+ {
+super(initialise(currentTokenVal, expectedTokenSequencesVal,
tokenImageVal));
+currentToken = currentTokenVal;
+expectedTokenSequences = expectedTokenSequencesVal;
+tokenImage = tokenImageVal;
+ }
+
+ /**
+ * The following constructors are for use by you for whatever
+ * purpose you can think of. Constructing the exception in this
+ * manner makes the exception behave in the normal way - i.e., as
+ * documented in the class "Throwable". The fields "errorToken",
+ * "expectedTokenSequences", and "tokenImage" do not contain
+ * relevant information. The JavaCC generated code does not use
+ * these constructors.
+ */
+
+ public ParseException() {
+super();
+ }
+
+ /** Constructor with message. */
+ public ParseException(String message) {
+super(message);
+ }
+
+
+ /**
+ * This is the last token that has been consumed successfully. If
+ * this object has been created due to a parse error, the token
+ * followng this token will (therefore) be the first error token.
+ */
+ public Token currentToken;
+
+ /**
+ * Each entry in this array is an array of integers. Each array
+ * of integers represents a sequence of tokens (by their ordinal
+ * values) that is expected at this point of the parse.
+ */
+ public int[][] expectedTokenSequences;
+
+ /**
+ * This is a reference to the "tokenImage" array of the generated
+ * parser within which the parse error occurred. This array is
+ * defined in the generated ...Constants interface.
+ */
+ public String[] tokenImage;
+
+ /**
+ * It uses "currentToken" and "expectedTokenSequences" to generate a
parse
+ * error message and returns it. If this object has been created
+ * due to a parse error, and you do not catch it (it gets thrown
+ * from the parser) the correct error message
+ * gets displayed.
+ */
+ private static String initialise(Token currentToken,
+ int[][] expectedTokenSequences,
+ String[] tokenImage) {
+String eol = System.getProperty("line.separator", "\n");
+StringBuffer expected = new StringBuffer();
+int maxSize = 0;
+for (int i = 0; i < expectedTokenSequences.length; i++) {
+ if (maxSize <
[GitHub] jena pull request #455: JENA-1584: A Javacc Turtle parser for reference.
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/455#discussion_r207735228
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/lang/extra/javacc/ParseException.java
---
@@ -0,0 +1,205 @@
+/* Generated By:JavaCC: Do not edit this line. ParseException.java Version
6.0 */
+/* JavaCCOptions:KEEP_LINE_COL=null */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.riot.lang.extra.javacc;
+
+/**
+ * This exception is thrown when parse errors are encountered.
+ * You can explicitly create objects of this exception type by
+ * calling the method generateParseException in the generated
+ * parser.
+ *
+ * You can modify this class to customize your error reporting
+ * mechanisms so long as you retain the public fields.
+ */
+public class ParseException extends Exception {
+
+ /**
+ * The version identifier for this Serializable class.
+ * Increment only if the serialized form of the
+ * class changes.
+ */
+ private static final long serialVersionUID = 1L;
+
+ /**
+ * This constructor is used by the method "generateParseException"
+ * in the generated parser. Calling this constructor generates
+ * a new object of this type with the fields "currentToken",
+ * "expectedTokenSequences", and "tokenImage" set.
+ */
+ public ParseException(Token currentTokenVal,
+int[][] expectedTokenSequencesVal,
+String[] tokenImageVal
+ )
+ {
+super(initialise(currentTokenVal, expectedTokenSequencesVal,
tokenImageVal));
+currentToken = currentTokenVal;
+expectedTokenSequences = expectedTokenSequencesVal;
+tokenImage = tokenImageVal;
+ }
+
+ /**
+ * The following constructors are for use by you for whatever
+ * purpose you can think of. Constructing the exception in this
+ * manner makes the exception behave in the normal way - i.e., as
+ * documented in the class "Throwable". The fields "errorToken",
+ * "expectedTokenSequences", and "tokenImage" do not contain
+ * relevant information. The JavaCC generated code does not use
+ * these constructors.
+ */
+
+ public ParseException() {
+super();
+ }
+
+ /** Constructor with message. */
+ public ParseException(String message) {
+super(message);
+ }
+
+
+ /**
+ * This is the last token that has been consumed successfully. If
+ * this object has been created due to a parse error, the token
+ * followng this token will (therefore) be the first error token.
+ */
+ public Token currentToken;
+
+ /**
+ * Each entry in this array is an array of integers. Each array
+ * of integers represents a sequence of tokens (by their ordinal
+ * values) that is expected at this point of the parse.
+ */
+ public int[][] expectedTokenSequences;
+
+ /**
+ * This is a reference to the "tokenImage" array of the generated
+ * parser within which the parse error occurred. This array is
+ * defined in the generated ...Constants interface.
+ */
+ public String[] tokenImage;
+
+ /**
+ * It uses "currentToken" and "expectedTokenSequences" to generate a
parse
+ * error message and returns it. If this object has been created
+ * due to a parse error, and you do not catch it (it gets thrown
+ * from the parser) the correct error message
+ * gets displayed.
+ */
+ private static String initialise(Token currentToken,
+ int[][] expectedTokenSequences,
+ String[] tokenImage) {
+String eol = System.getProperty("line.separator", "\n");
+StringBuffer expected = new StringBuffer();
--- End diff --
Not that it makes much difference, but I think this one is still
synchronized, so
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[ https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569456#comment-16569456 ] ASF GitHub Bot commented on JENA-1585: -- Github user afs commented on the issue: https://github.com/apache/jena/pull/456 No problem on timing - I found I'd tripped myself up moving java resources around and tested against a setup that had old and new location materials. TravisCI caught this for me. > Reorganize the Fuseki codebase to split the server engine classes from the > webapp classes > - > > Key: JENA-1585 > URL: https://issues.apache.org/jira/browse/JENA-1585 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.8.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > This is a step towards separate packages for the fuseki server engine (the > servlets, request routing, some Jetty related support code) and the webapp > version of Fuseki that becomes the war and standalong jar in > jena-fuseki-server. > This first step is code reorganization with module jena-fuseki-core to put > the webapp java code it separate packages to the rest of the engine. > When split, the current jena-fuseki-core tests would go into > jena-fuseki-weabpp because they test the full server. The non-UI embeddable > server jena-fuseki-embedded and jena-fuseki-basic already gets test in the > integration tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena issue #456: JENA-1585: Fuseki core reorg
Github user afs commented on the issue: https://github.com/apache/jena/pull/456 No problem on timing - I found I'd tripped myself up moving java resources around and tested against a setup that had old and new location materials. TravisCI caught this for me. ---
[GitHub] jena pull request #456: JENA-1585: Fuseki core reorg
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207735470
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/FusekiBuildLib.java
---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.fuseki.build;
+
+import org.apache.jena.fuseki.FusekiConfigException;
+import org.apache.jena.fuseki.webapp.SystemState;
+import org.apache.jena.query.* ;
+import org.apache.jena.rdf.model.Literal ;
+import org.apache.jena.rdf.model.Model ;
+import org.apache.jena.rdf.model.RDFNode ;
+import org.apache.jena.rdf.model.Resource ;
+import org.apache.jena.shared.PrefixMapping ;
+import org.apache.jena.vocabulary.RDFS ;
+
+public class FusekiBuildLib {
--- End diff --
Good idea. And, yes, it is the build-specific operations.
Done.
---
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[
https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569454#comment-16569454
]
ASF GitHub Bot commented on JENA-1585:
--
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207735470
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/FusekiBuildLib.java
---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.fuseki.build;
+
+import org.apache.jena.fuseki.FusekiConfigException;
+import org.apache.jena.fuseki.webapp.SystemState;
+import org.apache.jena.query.* ;
+import org.apache.jena.rdf.model.Literal ;
+import org.apache.jena.rdf.model.Model ;
+import org.apache.jena.rdf.model.RDFNode ;
+import org.apache.jena.rdf.model.Resource ;
+import org.apache.jena.shared.PrefixMapping ;
+import org.apache.jena.vocabulary.RDFS ;
+
+public class FusekiBuildLib {
--- End diff --
Good idea. And, yes, it is the build-specific operations.
Done.
> Reorganize the Fuseki codebase to split the server engine classes from the
> webapp classes
> -
>
> Key: JENA-1585
> URL: https://issues.apache.org/jira/browse/JENA-1585
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> This is a step towards separate packages for the fuseki server engine (the
> servlets, request routing, some Jetty related support code) and the webapp
> version of Fuseki that becomes the war and standalong jar in
> jena-fuseki-server.
> This first step is code reorganization with module jena-fuseki-core to put
> the webapp java code it separate packages to the rest of the engine.
> When split, the current jena-fuseki-core tests would go into
> jena-fuseki-weabpp because they test the full server. The non-UI embeddable
> server jena-fuseki-embedded and jena-fuseki-basic already gets test in the
> integration tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[ https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569449#comment-16569449 ] ASF GitHub Bot commented on JENA-1585: -- Github user kinow commented on the issue: https://github.com/apache/jena/pull/456 Great stuff! Noticed a few misspellings, and also had a question about when to use the new `FusekiBuildLib`. But other than that looks great! Thanks for the new comments, and removing unnecessary code (e.g. that one that simply did a `return;`). :tada: I also realized that I submitted my review at the same time you updated the branch with more commits I think (at least I received an e-mail from GitHub right after that). So apologies if my comments are now out of sync. Thanks > Reorganize the Fuseki codebase to split the server engine classes from the > webapp classes > - > > Key: JENA-1585 > URL: https://issues.apache.org/jira/browse/JENA-1585 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.8.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > This is a step towards separate packages for the fuseki server engine (the > servlets, request routing, some Jetty related support code) and the webapp > version of Fuseki that becomes the war and standalong jar in > jena-fuseki-server. > This first step is code reorganization with module jena-fuseki-core to put > the webapp java code it separate packages to the rest of the engine. > When split, the current jena-fuseki-core tests would go into > jena-fuseki-weabpp because they test the full server. The non-UI embeddable > server jena-fuseki-embedded and jena-fuseki-basic already gets test in the > integration tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #456: JENA-1585: Fuseki core reorg
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734465
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/FusekiBuildLib.java
---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.fuseki.build;
+
+import org.apache.jena.fuseki.FusekiConfigException;
+import org.apache.jena.fuseki.webapp.SystemState;
+import org.apache.jena.query.* ;
+import org.apache.jena.rdf.model.Literal ;
+import org.apache.jena.rdf.model.Model ;
+import org.apache.jena.rdf.model.RDFNode ;
+import org.apache.jena.rdf.model.Resource ;
+import org.apache.jena.shared.PrefixMapping ;
+import org.apache.jena.vocabulary.RDFS ;
+
+public class FusekiBuildLib {
--- End diff --
Is `FusekiBuildLib` going to replace `FusekiLib`? Would it be worth a
one/two lines comment explaining what each one does? Just so one does not
create a method in one, while the method was supposed to be in the other
class...
From a quick peek at the new classes, I think `FusekiLib` is for methods
used by Fuseki server, and `FusekiBuildLib` is more for handling
nodes/resources. In which case maybe `FusekiLib#addDataInto` methods sit in
between, but maybe could be in `FusekiBuildLib` too?
---
[GitHub] jena pull request #456: JENA-1585: Fuseki core reorg
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734729
--- Diff:
jena-fuseki2/jena-fuseki-embedded/src/main/java/org/apache/jena/fuseki/embedded/FusekiServer.java
---
@@ -246,6 +248,13 @@ public Builder enableStats(boolean withStats) {
return this;
}
+/** Add the "/$/ping" servlet that responds to HTTP very
efficiently.
+ * This is useful for testign whether a server is alove, for
example, from a load balencer.
--- End diff --
s/testign/testing & s/balencer/balancer
---
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[
https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569445#comment-16569445
]
ASF GitHub Bot commented on JENA-1585:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734465
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/FusekiBuildLib.java
---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.fuseki.build;
+
+import org.apache.jena.fuseki.FusekiConfigException;
+import org.apache.jena.fuseki.webapp.SystemState;
+import org.apache.jena.query.* ;
+import org.apache.jena.rdf.model.Literal ;
+import org.apache.jena.rdf.model.Model ;
+import org.apache.jena.rdf.model.RDFNode ;
+import org.apache.jena.rdf.model.Resource ;
+import org.apache.jena.shared.PrefixMapping ;
+import org.apache.jena.vocabulary.RDFS ;
+
+public class FusekiBuildLib {
--- End diff --
Is `FusekiBuildLib` going to replace `FusekiLib`? Would it be worth a
one/two lines comment explaining what each one does? Just so one does not
create a method in one, while the method was supposed to be in the other
class...
From a quick peek at the new classes, I think `FusekiLib` is for methods
used by Fuseki server, and `FusekiBuildLib` is more for handling
nodes/resources. In which case maybe `FusekiLib#addDataInto` methods sit in
between, but maybe could be in `FusekiBuildLib` too?
> Reorganize the Fuseki codebase to split the server engine classes from the
> webapp classes
> -
>
> Key: JENA-1585
> URL: https://issues.apache.org/jira/browse/JENA-1585
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> This is a step towards separate packages for the fuseki server engine (the
> servlets, request routing, some Jetty related support code) and the webapp
> version of Fuseki that becomes the war and standalong jar in
> jena-fuseki-server.
> This first step is code reorganization with module jena-fuseki-core to put
> the webapp java code it separate packages to the rest of the engine.
> When split, the current jena-fuseki-core tests would go into
> jena-fuseki-weabpp because they test the full server. The non-UI embeddable
> server jena-fuseki-embedded and jena-fuseki-basic already gets test in the
> integration tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jena pull request #456: JENA-1585: Fuseki core reorg
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734712
--- Diff:
jena-fuseki2/jena-fuseki-core/src/test/java/org/apache/jena/fuseki/package-info.java
---
@@ -16,38 +16,17 @@
* limitations under the License.
*/
-package org.apache.jena.fuseki.servlets;
-
-import java.io.* ;
-
/**
-* Code needed to implement an OutputStream that does nothing.
-*/
-
-
-public class NullOutputStream extends /*Filter*/OutputStream
-{
- public NullOutputStream()
- {
- }
-
- // The OutputStream operations
- @Override
-public void close() { /* .close() ;*/ }
- @Override
-public void flush() { /* .flush() ;*/ }
-
- // Need to implement this one.
- @Override
-public void write(int b) { /* .write(b) ;*/ }
- @Override
-public void write(byte b[]) { /* this.write(b, 0, b.length) ; */}
+ * This package has the Fuseki full server tests. ServerCtl manages a
full server for tetsing.
--- End diff --
s/tetsing/testing
---
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[
https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569444#comment-16569444
]
ASF GitHub Bot commented on JENA-1585:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734712
--- Diff:
jena-fuseki2/jena-fuseki-core/src/test/java/org/apache/jena/fuseki/package-info.java
---
@@ -16,38 +16,17 @@
* limitations under the License.
*/
-package org.apache.jena.fuseki.servlets;
-
-import java.io.* ;
-
/**
-* Code needed to implement an OutputStream that does nothing.
-*/
-
-
-public class NullOutputStream extends /*Filter*/OutputStream
-{
- public NullOutputStream()
- {
- }
-
- // The OutputStream operations
- @Override
-public void close() { /* .close() ;*/ }
- @Override
-public void flush() { /* .flush() ;*/ }
-
- // Need to implement this one.
- @Override
-public void write(int b) { /* .write(b) ;*/ }
- @Override
-public void write(byte b[]) { /* this.write(b, 0, b.length) ; */}
+ * This package has the Fuseki full server tests. ServerCtl manages a
full server for tetsing.
--- End diff --
s/tetsing/testing
> Reorganize the Fuseki codebase to split the server engine classes from the
> webapp classes
> -
>
> Key: JENA-1585
> URL: https://issues.apache.org/jira/browse/JENA-1585
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> This is a step towards separate packages for the fuseki server engine (the
> servlets, request routing, some Jetty related support code) and the webapp
> version of Fuseki that becomes the war and standalong jar in
> jena-fuseki-server.
> This first step is code reorganization with module jena-fuseki-core to put
> the webapp java code it separate packages to the rest of the engine.
> When split, the current jena-fuseki-core tests would go into
> jena-fuseki-weabpp because they test the full server. The non-UI embeddable
> server jena-fuseki-embedded and jena-fuseki-basic already gets test in the
> integration tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[
https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569446#comment-16569446
]
ASF GitHub Bot commented on JENA-1585:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/jena/pull/456#discussion_r207734729
--- Diff:
jena-fuseki2/jena-fuseki-embedded/src/main/java/org/apache/jena/fuseki/embedded/FusekiServer.java
---
@@ -246,6 +248,13 @@ public Builder enableStats(boolean withStats) {
return this;
}
+/** Add the "/$/ping" servlet that responds to HTTP very
efficiently.
+ * This is useful for testign whether a server is alove, for
example, from a load balencer.
--- End diff --
s/testign/testing & s/balencer/balancer
> Reorganize the Fuseki codebase to split the server engine classes from the
> webapp classes
> -
>
> Key: JENA-1585
> URL: https://issues.apache.org/jira/browse/JENA-1585
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> This is a step towards separate packages for the fuseki server engine (the
> servlets, request routing, some Jetty related support code) and the webapp
> version of Fuseki that becomes the war and standalong jar in
> jena-fuseki-server.
> This first step is code reorganization with module jena-fuseki-core to put
> the webapp java code it separate packages to the rest of the engine.
> When split, the current jena-fuseki-core tests would go into
> jena-fuseki-weabpp because they test the full server. The non-UI embeddable
> server jena-fuseki-embedded and jena-fuseki-basic already gets test in the
> integration tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[ https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569441#comment-16569441 ] ASF GitHub Bot commented on JENA-1585: -- GitHub user afs opened a pull request: https://github.com/apache/jena/pull/456 JENA-1585: Fuseki core reorg Class reorganisation within the the jena-fuseki-core module. jena-fuseki-embedded and jena-fuseki-basic changes show the cleaner split - no mention of the webapp or mgt packages where the webapp code now resides. You can merge this pull request into a Git repository by running: $ git pull https://github.com/afs/jena fuseki-reorg Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/456.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 #456 commit 1d41d2ce4975ebc34e8a4dd4ff67cf1100421856 Author: Andy Seaborne Date: 2018-08-04T20:56:23Z JENA-1585: Fuseki core reorg > Reorganize the Fuseki codebase to split the server engine classes from the > webapp classes > - > > Key: JENA-1585 > URL: https://issues.apache.org/jira/browse/JENA-1585 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.8.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > This is a step towards separate packages for the fuseki server engine (the > servlets, request routing, some Jetty related support code) and the webapp > version of Fuseki that becomes the war and standalong jar in > jena-fuseki-server. > This first step is code reorganization with module jena-fuseki-core to put > the webapp java code it separate packages to the rest of the engine. > When split, the current jena-fuseki-core tests would go into > jena-fuseki-weabpp because they test the full server. The non-UI embeddable > server jena-fuseki-embedded and jena-fuseki-basic already gets test in the > integration tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #456: JENA-1585: Fuseki core reorg
GitHub user afs opened a pull request: https://github.com/apache/jena/pull/456 JENA-1585: Fuseki core reorg Class reorganisation within the the jena-fuseki-core module. jena-fuseki-embedded and jena-fuseki-basic changes show the cleaner split - no mention of the webapp or mgt packages where the webapp code now resides. You can merge this pull request into a Git repository by running: $ git pull https://github.com/afs/jena fuseki-reorg Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/456.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 #456 commit 1d41d2ce4975ebc34e8a4dd4ff67cf1100421856 Author: Andy Seaborne Date: 2018-08-04T20:56:23Z JENA-1585: Fuseki core reorg ---
[jira] [Updated] (JENA-1585) Reorganize the Fuseki codebase to split the server engine classes from the webapp classes
[ https://issues.apache.org/jira/browse/JENA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1585: Summary: Reorganize the Fuseki codebase to split the server engine classes from the webapp classes (was: Rorganise the Fuseli code to split the server engine from the webapp machinary.) > Reorganize the Fuseki codebase to split the server engine classes from the > webapp classes > - > > Key: JENA-1585 > URL: https://issues.apache.org/jira/browse/JENA-1585 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.8.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > This is a step towards separate packages for the fuseki server engine (the > servlets, request routing, some Jetty related support code) and the webapp > version of Fuseki that becomes the war and standalong jar in > jena-fuseki-server. > This first step is code reorganization with module jena-fuseki-core to put > the webapp java code it separate packages to the rest of the engine. > When split, the current jena-fuseki-core tests would go into > jena-fuseki-weabpp because they test the full server. The non-UI embeddable > server jena-fuseki-embedded and jena-fuseki-basic already gets test in the > integration tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1585) Rorganise the Fuseli code to split the server engine from the webapp machinary.
Andy Seaborne created JENA-1585: --- Summary: Rorganise the Fuseli code to split the server engine from the webapp machinary. Key: JENA-1585 URL: https://issues.apache.org/jira/browse/JENA-1585 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Jena 3.8.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 3.9.0 This is a step towards separate packages for the fuseki server engine (the servlets, request routing, some Jetty related support code) and the webapp version of Fuseki that becomes the war and standalong jar in jena-fuseki-server. This first step is code reorganization with module jena-fuseki-core to put the webapp java code it separate packages to the rest of the engine. When split, the current jena-fuseki-core tests would go into jena-fuseki-weabpp because they test the full server. The non-UI embeddable server jena-fuseki-embedded and jena-fuseki-basic already gets test in the integration tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569438#comment-16569438
]
ASF GitHub Bot commented on JENA-1584:
--
GitHub user afs opened a pull request:
https://github.com/apache/jena/pull/455
JENA-1584: A Javacc Turtle parser for reference.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/afs/jena ttl-javacc
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/455.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 #455
commit 7fb8a91d0f799161c5694ef64c344bd41b7b7cc8
Author: Andy Seaborne
Date: 2018-07-31T11:05:07Z
JENA-1584: A Javacc Turtle parser for reference.
> Include a Javacc based Turtle parser in RIOT
>
>
> Key: JENA-1584
> URL: https://issues.apache.org/jira/browse/JENA-1584
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> Turtle is the basis for some additional languages (RDF*, SHACL and ShEX
> compact forms).
> The main RIOT Turtle parser is written for speed, with the tuned tokenizer
> and directly written java grammar parser. This makes it harder to reuse and
> extend.
> This ticket proposes including another RDF 1.1 compliant Turtle parser based
> on JavaCC to provide an easier route for additional languages by providing
> all the details of Turtle such as the tokens and prefix name handling, in a
> form more suitable as a base for the new language. It will still be by being
> a copy of the parser, system, not class inheritance.)
> RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
> tokens and several grammar rules.
> This would not be active by default (i.e. not a registered {{Lang}} and it's
> parser factory but registered by automatic initialization). It's test suite
> would be run in the build and pass the RDF 1.1 Turtle test suite.
>
> There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
> pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that
> read turtle files. It could be moved into the test area except there appear
> to be some legacy applications that only use jena-core.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1584) Include a Javacc based Turtle parser in RIOT
[
https://issues.apache.org/jira/browse/JENA-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-1584:
Description:
Turtle is the basis for some additional languages (RDF*, SHACL and ShEX compact
forms).
The main RIOT Turtle parser is written for speed, with the tuned tokenizer and
directly written java grammar parser. This makes it harder to reuse and extend.
This ticket proposes including another RDF 1.1 compliant Turtle parser based on
JavaCC to provide an easier route for additional languages by providing all the
details of Turtle such as the tokens and prefix name handling, in a form more
suitable as a base for the new language. It will still be by being a copy of
the parser, system, not class inheritance.)
RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
tokens and several grammar rules.
This would not be active by default (i.e. not a registered {{Lang}} and it's
parser factory but registered by automatic initialization). It's test suite
would be run in the build and pass the RDF 1.1 Turtle test suite.
There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that read
turtle files. It could be moved into the test area except there appear to be
some legacy applications that only use jena-core.
was:
Turtle is the basis for some additional languages (RDF*, SHACL and ShEX compact
forms).
The main RIOT Turtle parser is written for speed, with the tuned tokenizer and
directly written java grammar parser. This makes it harder to reuse and extend.
This ticket proposes including another RDF 1.1 compliant Turtle parser based on
JavaCC to provide an easier route for additional languages by providing all the
details of Turtle such as the tokens and prefix name handling, in a form more
suitable as a base for the new language. It will still be by being a copy of
the parser, system, not class inheritance.)
RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
tokens and several grammar rules.
There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that read
turtle files. It could be moved into the test area except there appear to be
some legacy applications that only use jena-core.
> Include a Javacc based Turtle parser in RIOT
>
>
> Key: JENA-1584
> URL: https://issues.apache.org/jira/browse/JENA-1584
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> Turtle is the basis for some additional languages (RDF*, SHACL and ShEX
> compact forms).
> The main RIOT Turtle parser is written for speed, with the tuned tokenizer
> and directly written java grammar parser. This makes it harder to reuse and
> extend.
> This ticket proposes including another RDF 1.1 compliant Turtle parser based
> on JavaCC to provide an easier route for additional languages by providing
> all the details of Turtle such as the tokens and prefix name handling, in a
> form more suitable as a base for the new language. It will still be by being
> a copy of the parser, system, not class inheritance.)
> RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share
> tokens and several grammar rules.
> This would not be active by default (i.e. not a registered {{Lang}} and it's
> parser factory but registered by automatic initialization). It's test suite
> would be run in the build and pass the RDF 1.1 Turtle test suite.
>
> There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the
> pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that
> read turtle files. It could be moved into the test area except there appear
> to be some legacy applications that only use jena-core.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jena pull request #455: JENA-1584: A Javacc Turtle parser for reference.
GitHub user afs opened a pull request: https://github.com/apache/jena/pull/455 JENA-1584: A Javacc Turtle parser for reference. You can merge this pull request into a Git repository by running: $ git pull https://github.com/afs/jena ttl-javacc Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/455.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 #455 commit 7fb8a91d0f799161c5694ef64c344bd41b7b7cc8 Author: Andy Seaborne Date: 2018-07-31T11:05:07Z JENA-1584: A Javacc Turtle parser for reference. ---
[jira] [Created] (JENA-1584) Include a Javacc based Turtle parser in RIOT
Andy Seaborne created JENA-1584: --- Summary: Include a Javacc based Turtle parser in RIOT Key: JENA-1584 URL: https://issues.apache.org/jira/browse/JENA-1584 Project: Apache Jena Issue Type: Improvement Components: RIOT Affects Versions: Jena 3.8.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 3.9.0 Turtle is the basis for some additional languages (RDF*, SHACL and ShEX compact forms). The main RIOT Turtle parser is written for speed, with the tuned tokenizer and directly written java grammar parser. This makes it harder to reuse and extend. This ticket proposes including another RDF 1.1 compliant Turtle parser based on JavaCC to provide an easier route for additional languages by providing all the details of Turtle such as the tokens and prefix name handling, in a form more suitable as a base for the new language. It will still be by being a copy of the parser, system, not class inheritance.) RDF 1.1 Turtle and SPARQL 1.1 were aligned by the working groups and share tokens and several grammar rules. There is non-RDF1.1 Javacc Turtle parser in jena-core is based on the pre-RDF1.1 state of Turtle. It is sufficient for the assembler tests that read turtle files. It could be moved into the test area except there appear to be some legacy applications that only use jena-core. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
