Claude,
OK - I understand that difference.
I'm interested in the maven structure.
jena-commons -+- jena-commons-config
|
+- jena-commons-querybuilder
|
+- ...
vs
jena-commons -+- jena-commons-querybuilder
|
+- ...
jena-labs -+- jena-commons-config
|
+- ...
jena-commons POM enumerates the artifacts under it. c.f. jena-jdbc
(drop "commons-" for sub-artifacts?)
jena-commons -+- jena-config
|
+- jena-querybuilder
I don't have a strong preference (at the moment :-) for nested vs flat
hierarchies. What do others think?
Andy
On 09/10/14 07:45, Claude Warren wrote:
I envisioned commons to be a package where classes that implemented
interfaces in other projects would be stored. For example the
implementation of Apache commons Configuration that uses a graph as the
backing store. Classes that make it easier to utilize Jena with other
tools/projects. Another example might be a class that plugs into fuseki to
expose the graph in DOT format for javascript based graph visualization
tools.
QueryBuilder is more of a tools that makes it easier to implement something
with Jena, which might make more sense in a Util or Labs module.
From a directory tree perspective perhaps it makes sense to do something
like
labs -+- module 1
|
+- module 2
|
+- module 3
Where each module is a Maven project in its own right, and with a page (or
section) on the website. Labs would have a POM file with basic
dependencies, etc.
So I am in agreement with not putting QueryBuilder into an existing module.
I would like to know if anyone sees merit to having a "Commons" and a "Lab"
sub project with the distinction noted above?
Claude
On Wed, Oct 8, 2014 at 9:36 PM, Andy Seaborne <[email protected]> wrote:
On 07/10/14 17:37, Bruno P. Kinoshita wrote:
My vote is not binding, but I'd be +1 for that. I'm using
ParameterizedSparqlString from ARQ to create simple INSERT's that will go
to a Fuseki SPARQL endpoint, but my guess is that QueryBuilder would ease
the other users to understand how the query was being built (pun intended :)
So you'll probably already have 1 user to annoy you with bug and feature
requests in the future.
CheersBruno
From: Claude Warren <[email protected]>
To: [email protected]
Sent: Tuesday, October 7, 2014 1:15 PM
Subject: Query Builder
Does anyone have an objection to adding the query builder code to the jena
project?
Does anyone have a suggestion for where to put it?
I assume we don't want it in ARQ (though the code is currently ARQ package
based).
It seems to me that it is a nice to have utility and should be packaged
with other nice to have utilities or perhaps on it's own.
Do we need to have a discussion and come to consensus about how to package
other similar packages?
Claude
Is this good timing for your idea of jena-commons [*]?
There are 3 choices:
1/ In an existing module
2/ In "jena-commons"
3/ In its own module
I think it's time we did less of (1); I'm fairly neutral on (2) or (3).
If part of a future commons becomes too large, too popular (!), or
whatever, we can move it to it's own module. Going into "commons" does not
fix it to commons for all time.
An area of the website could be the commons page with links to subpages
about each component.
The other thought I had was whether this is "labs" to label is as new and
making it clearer for changes that might not be perfectly compatible.
Andy
[*]
http://mail-archives.apache.org/mod_mbox/jena-dev/201406.
mbox/%3CCAOQrJk6qSX%2BKX3B7EFnd_qG6juqYWBUsbbUC5UaAyKwdxnDkeA%
40mail.gmail.com%3E
