On 22/07/14 15:47, Claude Warren wrote:
Looking back at the code again.. it does use the Jena Node and Resource
clases so it is Jena specific.
It could build an ARQ syntax tree -- I just didn't go that far with it.
I think there is a need for a Commons and have created jena-commons in the
Experimental branch.
Currently that only contains the Apache commons
Configuration implementation that uses Models to store the configuration
options.
I could add this there.
The current structure is of one big single area.
Shouldn't we have one module per item in commons?
I do want to come back to the matter of releases. Claude - how do you
see commons code being released?
Andy
I don't have a handle on git structure so I won't comment on that, but will
read and learn.
Claude
On Tue, Jul 22, 2014 at 1:33 PM, Andy Seaborne <[email protected]> wrote:
On 21/07/14 20:34, Claude Warren wrote:
I have code for a query builder that I would like to contribute... but I
don't see a good place to put the code.
It is not Jena specific.
So it's string based?
Can it (could it) build an ARQ syntax tree? That avoid the need to parse,
and makes it harder to have injection issues (accidental or not so
accidental).
it has the following methods
addFilter()
addGraph()
addOptional()
addOrderBy()
addPrefix()
addSubQuery()
addUnion()
addVar()
addWhere()
build()
clone()
the build() method creates a SELECT statement string.
the clone() makes a deep copy so it is easy to create a base query in code
and then extend it.
Anybody have any idea if and where it might go in the Jena source? Perhaps
the jena-commons experimental code?
Let's think this through for the general case. The question must be how
this fits into releases. Separate release? In conjunction with the main
release? If it's just source code hosting (no releases), github may be a
better choice. Releases have a special status.
It's also most as if "we" (the wider community inc users) would benefit
from something like Apache Commons. What else might be a candidate for
such a thing?
How might we structure the things so that the design works for git as well?
One possibility is that there is a number of different areas "trunk",
"commons"(or some such area like "modules", "main", ...)
But git will clone everything unlike svn that can pick and choose (isthat
correct for git these days?)
What I think we need to have a clear setup as to what's in the main
releases and what's an additional area so that people don't get the
expectation that an additional module is going to get released every main
release.
If we decide that it doesn't belong, I'll just create a git hub project
for
it.
Claude
WDYT?
Andy
