[GitHub] jena issue #177: Bump YASQE up to version 2.11.4

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/177
  
Added a new commit, and edited my comments and title. Now instead of 2.11.3 
it is 2.11.4. @LaurensRietveld warned me about a regression in 2.11.3 (big 
thanks!). 2.11.4 includes the fix to our issue, plus the fix to the regression.

FWIW, looks like the regression in 2.11.3 involved an infinite loop crash 
in the browser.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #178: Small optimization for writePrefixes()

[OmarElabd]

GitHub user OmarElabd opened a pull request:

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

Small optimization for writePrefixes()

I made a small change to the N3JenaWriterCommon writePrefixes function so 
that it does not need to make a call from the hashmap.

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

$ git pull https://github.com/OmarElabd/jena master

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

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


commit 84d99ae0689a1e833e54fb0a341a4a8107621657
Author: OmarElabd 
Date:   2016-10-14T03:30:51Z

modified writePrefixes so that it doesn't need to retrieve the value from 
the map




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
(going off pull/151.diff, which isn't always perfect):

There is still a global server created in fuseki1/ServerTest by:
```
static { allocServer() ; }
```
I don't know why that has been enabled. I have now completely removed it 
from the code - see a latest state of http_op_3. 

I can't see what code state you're working from. Could you push what you 
have?

There were more tidying up left over than I expected - I may have not 
committed the right set though a visual check didn't suggest any problems.

What you see is a symptom of the old and new server being around at the 
same time. I believe that the pooling client can cause old server to hang 
around because, as it is localhost, the pool has open TCP connections.  That's 
why `ServerCtl.setPoolingHttpClient` closes down the pool with explicit 
`.close`.



> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
(going off pull/151.diff, which isn't always perfect):

There is still a global server created in fuseki1/ServerTest by:
```
static { allocServer() ; }
```
I don't know why that has been enabled. I have now completely removed it 
from the code - see a latest state of http_op_3. 

I can't see what code state you're working from. Could you push what you 
have?

There were more tidying up left over than I expected - I may have not 
committed the right set though a visual check didn't suggest any problems.

What you see is a symptom of the old and new server being around at the 
same time. I believe that the pooling client can cause old server to hang 
around because, as it is localhost, the pool has open TCP connections.  That's 
why `ServerCtl.setPoolingHttpClient` closes down the pool with explicit 
`.close`.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
Do you have any changes other than those I picked up with the merge?

If not, the simple way is to work from http_op_3 which I can do - it 
includes all your commits on this PR (unlike http_op_2 where I didn't do the 
merge cleanly so I got the changes but lost the commit structure).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
Do you have any changes other than those I picked up with the merge?

If not, the simple way is to work from http_op_3 which I can do - it 
includes all your commits on this PR (unlike http_op_2 where I didn't do the 
merge cleanly so I got the changes but lost the commit structure).


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
I will bang on this more this weekend and try going back down the road you 
outlined, @afs . Maybe I missed something in the way I brought your commit 
over. If I don't find something, I'll go back through the test server 
management machinery. There must be something there.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
I will bang on this more this weekend and try going back down the road you 
outlined, @afs . Maybe I missed something in the way I brought your commit 
over. If I don't find something, I'll go back through the test server 
management machinery. There must be something there.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs I'm still getting the errors:
```
Failed tests:
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_01:531
 expected:<10> but was:<0>
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_02:578
 expected:<1> but was:<0>
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_03:625
 expected:<10> but was:<0>
```

running `mvn clean install` your branch `http_op_3` directly or now that I 
have cherry-picked 
https://github.com/apache/jena/commit/36b678933ecf2b5553f9345ef84e683cf0f181f0 
onto this PR. Did I miss something in the plan you laid out? 


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs I'm still getting the errors:
```
Failed tests:
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_01:531
 expected:<10> but was:<0>
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_02:578
 expected:<1> but was:<0>
  
TestRemoteEndpointConnectionWithResultSetTypes>AbstractJenaConnectionTests.connection_statement_query_select_max_rows_03:625
 expected:<10> but was:<0>
```

running `mvn clean install` your branch `http_op_3` directly or now that I 
have cherry-picked 
https://github.com/apache/jena/commit/36b678933ecf2b5553f9345ef84e683cf0f181f0 
onto this PR. Did I miss something in the plan you laid out? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Hang on, I didn't realize that that was just a simple cherry-pick, doing it 
now.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Hang on, I didn't realize that that was just a simple cherry-pick, doing it 
now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Are you saying to take 
https://github.com/apache/jena/commit/36b678933ecf2b5553f9345ef84e683cf0f181f0 
and add it to this PR, and then we can look at finally merging this into 
master? Yes, I can totally do that, although it's COB today here and I am 
traveling all day tomorrow, so I will not be able to get to it until Saturday. 
But I will surely do it then.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Are you saying to take 
https://github.com/apache/jena/commit/36b678933ecf2b5553f9345ef84e683cf0f181f0 
and add it to this PR, and then we can look at finally merging this into 
master? Yes, I can totally do that, although it's COB today here and I am 
traveling all day tomorrow, so I will not be able to get to it until Saturday. 
But I will surely do it then.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
> Let's port the changes here, where the discussion has been.

Branch  [http_op_3](https://github.com/afs/jena/tree/http_op_3) is made by:

1. Current Jena master.
1. This PR
1. Resolve merge conflict 
1. Commit merge : 8c2935e
1. Overlay the java files from branch http_op_2
1. Commit changes: 36b6789

So that is the correctly consolidated set of changes.

@ajs6f - would it work for you to commit 36b6789 and you make it this PR? 
Or what else?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
> Let's port the changes here, where the discussion has been.

Branch  [http_op_3](https://github.com/afs/jena/tree/http_op_3) is made by:

1. Current Jena master.
1. This PR
1. Resolve merge conflict 
1. Commit merge : 8c2935e
1. Overlay the java files from branch http_op_2
1. Commit changes: 36b6789

So that is the correctly consolidated set of changes.

@ajs6f - would it work for you to commit 36b6789 and you make it this PR? 
Or what else?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: RDF Patch - experiences suggesting changes

[Paul Houle]

There is another use case for an "RDF Patch" which applies to
hand-written models.  For instance I have a model which describes a job
that is run in AWS that looks like

@prefix : 
@prefix parameter: 

:Server
   :subnetId "subnet-e0ab0197";
   :baseImage "ami-ea602afd";
   :instanceType "r3.xlarge";
   :keyName "o2key";
   :keyFile "~/AMZN Keys/o2key.ppk" ;
   :securityGroupIds "sg-bca0b2d9" ;
   :todo "dbpedia-load" ;
   parameter:RDF_SOURCE "s3://abnes/dbpedia/2015-10-gz/" ;
   parameter:GRAPH_NAME "http://dbpedia.org/; ;
   :imageCommand "/home/ubuntu/RDFeasy/bin/shred_evidence_and_halt";
   :iamProfile  ;
   :instanceName "Image Build Server";
   :qBase  .

one thing you might want to do is modify it so it uses a different
:baseImage or a different :instanceType and a natural way to do that is
to say

'remove :Server :instanceType ?x and insert :Server :instanceType
"r3.2xlarge"'

but better than that if you have a schema that says ":instanceType is a
single valued property" you can write another graph like

:Server
   :instanceType "r3.2xlarge" .

and merge it with the first graph to get the desired effect.

More generally this fits into the theme that "the structure of
commonsense knowledge is that there are rules,  then exceptions to the
rules,  then exceptions to the exceptions of the rules,  etc."

For instance I extracted a geospatial database out of Freebase that was
about 10 million facts and I found I had to add and remove about 10
facts on the route to a 99% success rate at a geospatial recognition
task.  A disciplined approach to "agreeing to disagree" goes a long way
to solve the problem that specific applications require us to split
hairs in different ways.



-- 
  Paul Houle
  paul.ho...@ontology2.com

On Thu, Oct 13, 2016, at 11:32 AM, Andy Seaborne wrote:
> I've been using modified RDF Patch for the data exchanged to keep 
> multiple datasets synchronized.
> 
> My primary use case is having multiple copies of the datasets for a high 
> availability solution.  It has to be a general solution for any data.
> 
> There are some changes to the format that this work has highlighted.
> 
> [RDF Patch - v1]
> https://afs.github.io/rdf-patch/
> 
> 
> 1/ Record changes to prefixes
> 
> Just handling quads/triples isn't enough - to keep two datasets in-step, 
> we also need to record changes to prefixes.  While they don't change the 
> meaning of the data, application developers and users like prefixes.
> 
> 2/ Remove the in-data prefixes feature.
> 
> RDF Patch has the feature to define prefixes in the data and use them 
> for prefix names later in the data using @prefix.
> 
> This seems to have no real advantage, it can slow things down (c.f. 
> N-Triples parsing is faster than Turtle parsing - prefixes is part of 
> that), and it generally complicates the data form.
> 
> When including "add"/"delete" prefixes on the dataset (1) it also makes 
> it quite confusing.
> 
> Whether the "R" for "repeat" entry from previous row should also be 
> removed is an open question.
> 
> 3/ Record transaction boundaries.
> 
> (A.3 in RDF Patch v1)
> http://afs.github.io/rdf-patch/#transaction-boundaries
> 
> Having the transaction boundaries recorded means that they can be 
> replayed when applying the patch.  While often a patch will be one 
> transaction, patches can be consolidated by concatenation.
> 
> There 3 operations:
> 
> TB, TC, TA - Transaction Begin, Commit, Abort.
> 
> Abort is useful to include because to know whether a transaction in a 
> patch is going to commit or abort means waiting until the end.  That 
> could be buffering client-side, or buffering server-side (or not writing 
> the patch to a file) and having a means to discard a patch stream.
> 
> Instead, allow a transaction to record an abort, and say that aborted 
> transactions in patches can be discarded downstream.
> 
> 4/ Reversibility is a patch feature.
> 
> The RDF Patch v1 document includes "canonical patch" (section 9)
> http://afs.github.io/rdf-patch/#canonical-patches
> 
> Such a patch is reversible (it can undo changes) if the adds and deletes 
> are recorded only if they lead to a real change.  "Add quad" must mean 
> "there was no quad in the set before".  But this only makes sense if the 
> whole patch has this property.
> 
> RDF Patches are in general entries in a "redo log" - you can apply the 
> patch over and over again and it will end up in the same state (they are 
> idempotent).
> 
> A reversible patch is also an "undo log" entry and if you apply it in 
> reverse order, it acts to undo the patch played forwards.
> 
> Testing whether a triple or quad is already present while performing 
> updates is not cheap - and in some cases where the patch is being 
> computed without reference to an existing dataset may not be possible.
> 
> What would be useful is to label the patch 

RDF Patch - experiences suggesting changes

[Andy Seaborne]

I've been using modified RDF Patch for the data exchanged to keep 
multiple datasets synchronized.


My primary use case is having multiple copies of the datasets for a high 
availability solution.  It has to be a general solution for any data.


There are some changes to the format that this work has highlighted.

[RDF Patch - v1]
https://afs.github.io/rdf-patch/


1/ Record changes to prefixes

Just handling quads/triples isn't enough - to keep two datasets in-step, 
we also need to record changes to prefixes.  While they don't change the 
meaning of the data, application developers and users like prefixes.


2/ Remove the in-data prefixes feature.

RDF Patch has the feature to define prefixes in the data and use them 
for prefix names later in the data using @prefix.


This seems to have no real advantage, it can slow things down (c.f. 
N-Triples parsing is faster than Turtle parsing - prefixes is part of 
that), and it generally complicates the data form.


When including "add"/"delete" prefixes on the dataset (1) it also makes 
it quite confusing.


Whether the "R" for "repeat" entry from previous row should also be 
removed is an open question.


3/ Record transaction boundaries.

(A.3 in RDF Patch v1)
http://afs.github.io/rdf-patch/#transaction-boundaries

Having the transaction boundaries recorded means that they can be 
replayed when applying the patch.  While often a patch will be one 
transaction, patches can be consolidated by concatenation.


There 3 operations:

TB, TC, TA - Transaction Begin, Commit, Abort.

Abort is useful to include because to know whether a transaction in a 
patch is going to commit or abort means waiting until the end.  That 
could be buffering client-side, or buffering server-side (or not writing 
the patch to a file) and having a means to discard a patch stream.


Instead, allow a transaction to record an abort, and say that aborted 
transactions in patches can be discarded downstream.


4/ Reversibility is a patch feature.

The RDF Patch v1 document includes "canonical patch" (section 9)
http://afs.github.io/rdf-patch/#canonical-patches

Such a patch is reversible (it can undo changes) if the adds and deletes 
are recorded only if they lead to a real change.  "Add quad" must mean 
"there was no quad in the set before".  But this only makes sense if the 
whole patch has this property.


RDF Patches are in general entries in a "redo log" - you can apply the 
patch over and over again and it will end up in the same state (they are 
idempotent).


A reversible patch is also an "undo log" entry and if you apply it in 
reverse order, it acts to undo the patch played forwards.


Testing whether a triple or quad is already present while performing 
updates is not cheap - and in some cases where the patch is being 
computed without reference to an existing dataset may not be possible.


What would be useful is to label the patch itself to say whether it is 
reversible.


5/ "RDF Git"

A patch should be able to record where it can be applied.  If RDF Patch 
is being used to keep two datasets in-step, then some checking to know 
that the patch can be applied to a copy because it is a patch created 
from the previous version


So give each version of the dataset a UUID for a version then record the 
old ("parent") UUID and the new UUID in the patch.


If the version checked and enforced, we get a chain of versions and 
patches that lead from one state to another without risk of concurrent 
changes getting mixed in.


This is like git - a patch can be accepted if the versions align 
otherwise it is rejected (more a git repo not accepting a push than a 
merge conflict).


Or some system may want to apply any patch and so create a tree of 
changes.  For the use case of keeping two datasets in-step, that's not 
what is wanted but other use cases may be better served by having the 
primary version chain sorted out by higher level software; a patch may 
be a "proposed change".


6/ Packets of change.

To have 4 (label a patch with reversible) and 5 (the version details), 
there needs to be somewhere to put the information. Having it in the 
patch itself means that the whole unit can be stored in a file.  If it 
is in the protocol, like HTTP for E-tags then the information becomes 
separated.  That is not to say that it can't also be in the protocol but 
it needs support in the data format.


7/ Checksum

Another feature to add to the packet is a checksum. A hash (which one? 
git uses SHA1) from start of packet header, including the initial 
version (UUID), the version on applying the patch (UUID) and the changes 
(i.e. start of packet to after the DOT of the last line of change), 
makes the packet robust to editting after creating it.   Like git; git 
uses it as the "object id".


So a patch packet for a single transaction:

PARENT 
VERSION 
REVERSIBLE   optional
TB
QA ...
QD ...
PA ...
PD ...
TC
H 

where QA and QD are "quad add" "quad delete", and "PA" "PD" are "add 
prefix" 

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
1. Let's port the changes here, where the discussion has been.

2. Absolutely fine with me (to do the other changes elsewhere). I'll make a 
ticket for those things now so that we don't lose the thread.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
I've opened https://issues.apache.org/jira/browse/JENA-1243 to track the 
other clear-up.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
I've opened https://issues.apache.org/jira/browse/JENA-1243 to track the 
other clear-up.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (JENA-1243) Remove cruft from JDBC modules

[A. Soroka (JIRA)]

A. Soroka created JENA-1243:
---

 Summary: Remove cruft from JDBC modules
 Key: JENA-1243
 URL: https://issues.apache.org/jira/browse/JENA-1243
 Project: Apache Jena
  Issue Type: Task
  Components: JDBC
Reporter: A. Soroka
Priority: Minor


There are some leftovers in the JDBC modules that we can remove, as documented 
here:

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

Specifically, there is an inappropriate usage of 
com.mycila.maven-license-plugin, also an unnecessary override of 
maven-source-plugin, and lastly a dependency on AspectJ which doesn't seem to 
be needed any more.



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
1. Let's port the changes here, where the discussion has been.

2. Absolutely fine with me (to do the other changes elsewhere). I'll make a 
ticket for those things now so that we don't lose the thread.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
Can we do the clear-up separately, please? I really want to get he HTTP 
changes into the code base as this is in practical terms a blocker on the 
release preparation so I'm keen to get what we have into the codebase so it can 
settle even if the settling is short.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
Can we do the clear-up separately, please? I really want to get he HTTP 
changes into the code base as this is in practical terms a blocker on the 
release preparation so I'm keen to get what we have into the codebase so it can 
settle even if the settling is short.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
@ajs6f  Do you want me to PR the http_op_2 branch then? (because of the 
conflict it lost the separate commits along the way.) Or port the change to 
this PR? I don't mind either way.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r83228882
  
--- Diff: jena-fuseki1/src/test/java/org/apache/jena/fuseki/ServerTest.java 
---
@@ -20,7 +20,7 @@
 
 import java.io.IOException ;
 import java.net.ServerSocket ;
-import java.util.Arrays ;
+import java.util.concurrent.atomic.AtomicInteger;
--- End diff --

It can stay - I was just highlighting there is no concurrency issue at this 
point.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena pull request #151: JENA-576: Moving away from deprecated HttpCommons Cl...

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r83228882
  
--- Diff: jena-fuseki1/src/test/java/org/apache/jena/fuseki/ServerTest.java 
---
@@ -20,7 +20,7 @@
 
 import java.io.IOException ;
 import java.net.ServerSocket ;
-import java.util.Arrays ;
+import java.util.concurrent.atomic.AtomicInteger;
--- End diff --

It can stay - I was just highlighting there is no concurrency issue at this 
point.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
The incorrect/ overridden plug-ins can certainly be removed. They are 
probably just cruft from the early days of development.

Historically AspectJ was used in order to inject trace level logging into 
every single method in the JDBC code base. The logic behind this was that the 
intent was for the driver to be used with generic JDBC tools where attaching a 
debugger would have been difficult/impossible and so you would've had to rely 
on logging to do debugging. This probably doesn't apply any more so you may as 
well remove it. There may be associated entries in the license/notice that 
should also be removed. But this was three years ago so my memory maybe 
incorrect.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[rvesse]

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
The incorrect/ overridden plug-ins can certainly be removed. They are 
probably just cruft from the early days of development.

Historically AspectJ was used in order to inject trace level logging into 
every single method in the JDBC code base. The logic behind this was that the 
intent was for the driver to be used with generic JDBC tools where attaching a 
debugger would have been difficult/impossible and so you would've had to rely 
on logging to do debugging. This probably doesn't apply any more so you may as 
well remove it. There may be associated entries in the license/notice that 
should also be removed. But this was three years ago so my memory maybe 
incorrect.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r83219299
  
--- Diff: jena-fuseki1/src/test/java/org/apache/jena/fuseki/ServerTest.java 
---
@@ -20,7 +20,7 @@
 
 import java.io.IOException ;
 import java.net.ServerSocket ;
-import java.util.Arrays ;
+import java.util.concurrent.atomic.AtomicInteger;
--- End diff --

I have no problem switching it back. I liked the clarity and concision of 
`getAndIncrement()` and `decrementAndGet()`, but maybe that's just me.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena pull request #151: JENA-576: Moving away from deprecated HttpCommons Cl...

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r83219299
  
--- Diff: jena-fuseki1/src/test/java/org/apache/jena/fuseki/ServerTest.java 
---
@@ -20,7 +20,7 @@
 
 import java.io.IOException ;
 import java.net.ServerSocket ;
-import java.util.Arrays ;
+import java.util.concurrent.atomic.AtomicInteger;
--- End diff --

I have no problem switching it back. I liked the clarity and concision of 
`getAndIncrement()` and `decrementAndGet()`, but maybe that's just me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Holy moly, @afs , thanks for the huge assist! I was out yesterday (Yom 
Kippur) and am now catching up. I will leave comments specific to the HTTP 
question on the new PR, but I will try to speak to the other points here.

1. I am certainly happy to see a spurious plugin go. I have no problem with 
including that change in this package of changes, if that's okay with everyone 
else. Or it could be a quick separate ticket/commit, to keep thing straighter 
in the history.

2. I have no idea why `maven-source-plugin ` is overridden. Baggage from 
long-ago when this material was imported into the main code base?

3. I haven't seen AspectJ used anywhere, but I haven't been all through the 
`jdbc` code. Same as the first point-- I have no problem removing it here or 
elsewhere.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



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

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Holy moly, @afs , thanks for the huge assist! I was out yesterday (Yom 
Kippur) and am now catching up. I will leave comments specific to the HTTP 
question on the new PR, but I will try to speak to the other points here.

1. I am certainly happy to see a spurious plugin go. I have no problem with 
including that change in this package of changes, if that's okay with everyone 
else. Or it could be a quick separate ticket/commit, to keep thing straighter 
in the history.

2. I have no idea why `maven-source-plugin ` is overridden. Baggage from 
long-ago when this material was imported into the main code base?

3. I haven't seen AspectJ used anywhere, but I haven't been all through the 
`jdbc` code. Same as the first point-- I have no problem removing it here or 
elsewhere.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---