At first I didn't have an opinion until I realized that if a module "graduates" to a higher level then the name would change (eg jenna-commons-querybuilder -> jena-querybuilder) so I think that we drop the commons/lab from the sub-artifacts so jena-commons -+- jena-config
and jena-lab -+- jena-querybuilder Since this naming scheme allows for easy movement of sub-artifacts I would be happy to put both jena-config and jena-querybuilder under lab for the time being. If we get more commons type implementations we can split it off later. Comments? Claude On Thu, Oct 9, 2014 at 2:32 PM, Andy Seaborne <[email protected]> wrote: > 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 >>> >>> >> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
