Re: [GSoC 2015 - JENA-491] Refactoring Template

2015-06-21 Thread Qihong Lin
On Tue, Jun 16, 2015 at 7:19 PM, Andy Seaborne a...@apache.org wrote:
 On 15/06/15 11:36, Qihong Lin wrote:

 Hi,

 Please check my last 3 commits[1], related to refactoring Template.
 master.jj is modified accordingly, *without* implementing the new
 CONSTRUCT query function for quad. Just to make sure: the maven build
 test for this jena-arq module is successful.

 Here're some ideas for to discuss:

 (1) Leaving the existing methods/constructors in-place , such as new
 Template(basic graph pattern), so the source code for the SPARQL 1.0
 parser does not need change.


 Good!

 (2) Add new constructors of Template(QuadAcc qp) for future use for
 the new CONSTRUCT query for quad. I use QuadAcc here (instead of
 QuadPattern), because other parts of master.jj use it for parsing
 quads.


 That's workable but it could be a bit neater with a builder pattern like the
 current Template(BGP).

 The original code had TripleCollectorBGP as the builder and when it's
 finished the parsing step for the CONSTRUCT template, there is a call of
 getBGP() that yields the BGP.  They may not be a real copy - that's an
 efficiency hack, not a design issue.

 Template for quads should follow the same pattern.  The constructor for
 Template can take ListQuad (or add getQuadPattern to QuadAcc c.f.
 TripleCollectorBGP.getBGP)

 (Admittedly, the existing code should also do this in other places. Code
 grows organically over a long period.  Consistency is unlikely!)

 Why can't you use  QuadPattern(QuadAcc) in ARQ-ConstructQuery?

 Andy

Because our ('GRAPH'  VarOrIri)? definition is optional. It requires
more flexible than QuadPattern. In QuadPattern, 'GRAPH' token can not
be omitted.






 Anything inappropriate? If it's generally OK, I'd like to continue
 working on master.jj.


 Great.



 regards,
 Qihong


 [1] https://github.com/confidencesun/jena/commits/JENA-491




Re: [GSoC 2015 - JENA-491] Refactoring Template

2015-06-21 Thread Qihong Lin
Hi,

Here some examples to try:
https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java

You can see that SPARQL 1.1 remains unchanged, both for sparql_11.jj
and the generated parser code.

regards,
Qihong

On Tue, Jun 16, 2015 at 9:04 PM, Andy Seaborne a...@apache.org wrote:
 On 16/06/15 12:19, Andy Seaborne wrote:

 On 15/06/15 11:36, Qihong Lin wrote:

 Hi,

 Please check my last 3 commits[1], related to refactoring Template.
 master.jj is modified accordingly, *without* implementing the new
 CONSTRUCT query function for quad. Just to make sure: the maven build
 test for this jena-arq module is successful.


 Is there an example that I can try?



 You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone. It's
 only the ARQ-extended form that should have your grammar.  The SPARQL 1.1
 parser (like the SPARQL 1.0 parser) will be unchanged although changes in
 whitespace etc in the generated java will get in the way of seeing that.

 master.jj:


 #ifdef ARQ
 void ConstructQuery() ;  { Template t ;
   QuadAcc acc = new QuadAcc() ; }
 ...
 #else
 void ConstructQuery() : { Template t ;
   QuadAcc acc = new QuadAcc() ; }

 This second branch should be the same bytes as the existing master.jj:

 void ConstructQuery() : { Template t ;
   TripleCollectorBGP acc = new TripleCollectorBGP()
 ; }
 {
 ...


 You can test from the command line using the arq.qparse tool.  Either

 java -cp ... arq.qparse --syntax=ARQ --file=...

 or

 java -cp ... arq.qparse --file=Q.arq

 The .arq extension will change it to ARQ syntax.

 I'm looking forward to trying it out ...

 Andy


 Here're some ideas for to discuss:

 (1) Leaving the existing methods/constructors in-place , such as new
 Template(basic graph pattern), so the source code for the SPARQL 1.0
 parser does not need change.


 Good!

 (2) Add new constructors of Template(QuadAcc qp) for future use for
 the new CONSTRUCT query for quad. I use QuadAcc here (instead of
 QuadPattern), because other parts of master.jj use it for parsing
 quads.


 That's workable but it could be a bit neater with a builder pattern like
 the current Template(BGP).

 The original code had TripleCollectorBGP as the builder and when it's
 finished the parsing step for the CONSTRUCT template, there is a call of
 getBGP() that yields the BGP.  They may not be a real copy - that's an
 efficiency hack, not a design issue.

 Template for quads should follow the same pattern.  The constructor for
 Template can take ListQuad (or add getQuadPattern to QuadAcc c.f.
 TripleCollectorBGP.getBGP)

 (Admittedly, the existing code should also do this in other places. Code
 grows organically over a long period.  Consistency is unlikely!)

 Why can't you use  QuadPattern(QuadAcc) in ARQ-ConstructQuery?

  Andy



 Anything inappropriate? If it's generally OK, I'd like to continue
 working on master.jj.


 Great.


 regards,
 Qihong


 [1] https://github.com/confidencesun/jena/commits/JENA-491





Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

2015-06-21 Thread Qihong Lin
Hi,

Please check my commits [1]. For quick answers below:

On Thu, Jun 18, 2015 at 6:18 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 You may have already received an email from Google, which reminded us
 of the mid-term evaluation for the GSoC project. The evaluation will
 start next Friday, 26 June. The deadline to submit your evaluation is
 19:00 UTC on Friday, 3 July. Please make sure not to miss it.

 More importantly, you're supposed to deliver your work according to
 the proposal before that. At least, I need to check the following
 output for the evaluation of your work:
 1) the grammar definition: normative definition of the syntax

It follows the proposal doc here [2].

 2) the new master.jj, arq.jj, with sparql_11.jj unchanged.

Yeah, sparql_11.jj is now unchanged.

 3) the code of new QueryExecution operations: execConstrucQuads(),
 execConstructDataset()

Done!

 4) some test code for the above, OR at least some examples/demos to
 prove your work

Here are some examples in ExampleConstructQuads.java [3]


 Best regards,
 Ying Jiang


[1] https://github.com/confidencesun/jena/commits/JENA-491
[2] 
https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit#
[3] 
https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java


regards,
Qihong


Re: Build failed in Jenkins: Jena_Development_Test_Windows ยป Apache Jena - Core #578

2015-06-21 Thread Claude Warren
I did some investigation over the weekend and think I found the problem.  I
took a couple of steps to try and resolve it.

1) I create a Jenkins build for Jena2
2) I used that build to debug the issue with the tests which did not occur
on my home system.
3) I managed to find what I think is the problem.

I have update the junit-contracts to 0.1.4 and have kicked off the jena2
build.  If the jena2 build succeeds then it should be safe to move jena
master to 0.1.4 as well and that should  resolve the build problem.

It is late here and I am heading to bed, but I will check tomorrow when I
get home and will perform the necessary updates to jena master if jena 2
succeeded.

Claude

On Wed, Jun 17, 2015 at 8:01 PM, Claude Warren cla...@xenei.com wrote:

 hmmm Looking at the code..

 The only unusual thing that the contract test does is build a class path
 that is then used to find the classes that are under test.

 I noticed in the Linux case it also failed the contract code.  The issue
 was that it could not find the dependency in any of the repositories.  So
 the contract test code there did not execute at all.

 I suppose I should put in an info log that will indicate when the plugin
 exits.

 I have found that the system could throw a SecurityException if it can't
 create the contract-reports sub-directory in the target directory.

 Looking through the code there are several places where RuntimeExceptions
 can be thrown.  I am not certain what the Maven Mojo does in that case.
 Thinking about it now, I can see that the RuntimeException should probably
 be caught and thrown as a MojoExecutionException to keep it from
 interrupting the flow of the build.




 On Wed, Jun 17, 2015 at 11:19 AM, Andy Seaborne a...@apache.org wrote:

 Correlation is not causality ... but!

 Claude,

 The Windows job stopped working last time around the time the version of
 the contract code was updated.

 Last time, I wiped the workspace out which seemed to get it working again
 - I don't know what's going on why.  The maven output does not show any
 problems - but jena-core is marked fail.

 Does the contract-test-maven-plugin do anything funky?

 I've wiped the workspace but it didn't recover this time.

 And as to why Windows not Ubuntu, ... simply no idea ...

 Lost in maven ...

 Andy

 On 17/06/15 10:23, Apache Jenkins Server wrote:

 See 
 https://builds.apache.org/job/Jena_Development_Test_Windows/org.apache.jena$jena-core/578/changes
 

 Changes:

 [andy] Put back contract plugin (Windows build testing)

 [claude] converted junit-contracts to version 0.1.3



  [INFO] --- contract-test-maven-plugin:0.1.2:contract-test (default) @
 jena-core ---
 [INFO] Processing package: org.apache.jena.assembler
 [INFO] Processing package: org.apache.jena.datatypes
 [INFO] Processing package: org.apache.jena.enhanced
 [INFO] Processing package: org.apache.jena.graph
 [INFO] Processing package: org.apache.jena.mem
 [INFO] Processing package: org.apache.jena.n3
 [INFO] Processing package: org.apache.jena.ontology
 [INFO] Processing package: org.apache.jena.rdf
 [INFO] Processing package: org.apache.jena.rdfxml
 [INFO] Processing package: org.apache.jena.reasoner
 [INFO] Processing package: org.apache.jena.shared
 [INFO] Processing package: org.apache.jena.util
 [INFO] Processing package: org.apache.jena.vocabulary
 [INFO] Skip filter: Not( Wildcard( Sensitive, *.test.* ) )
 [JENKINS] Archiving disabled





 --
 I like: Like Like - The likeliest place on the web
 http://like-like.xenei.com
 LinkedIn: http://www.linkedin.com/in/claudewarren




-- 
I like: Like Like - The likeliest place on the web
http://like-like.xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren


[jira] [Created] (JENA-971) QueryBuilder does not properly construct UNIONs

2015-06-21 Thread Claude Warren (JIRA)
Claude Warren created JENA-971:
--

 Summary: QueryBuilder does not properly construct UNIONs
 Key: JENA-971
 URL: https://issues.apache.org/jira/browse/JENA-971
 Project: Apache Jena
  Issue Type: Bug
  Components: Jena
Affects Versions: Jena 2.13.1, Jena 3.0.0
Reporter: Claude Warren
Assignee: Claude Warren


The QueryBuilder method addUnion() always adds a new union to the query 
pattern.  It should only add one if the last element in the query pattern is 
not a union.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (JENA-971) QueryBuilder does not properly construct UNIONs

2015-06-21 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/JENA-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595008#comment-14595008
 ] 

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

Commit 3206439e9132cf18b2ec16becb5b6c832b8de8e6 in jena's branch 
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=3206439 ]

Changes to fix JENA-971


 QueryBuilder does not properly construct UNIONs
 ---

 Key: JENA-971
 URL: https://issues.apache.org/jira/browse/JENA-971
 Project: Apache Jena
  Issue Type: Bug
  Components: Jena
Affects Versions: Jena 2.13.1, Jena 3.0.0
Reporter: Claude Warren
Assignee: Claude Warren

 The QueryBuilder method addUnion() always adds a new union to the query 
 pattern.  It should only add one if the last element in the query pattern is 
 not a union.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)