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 <a...@apache.org> 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 <cla...@xenei.com>
>> To: dev@jena.apache.org
>> 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
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
