Be good to split out LARQ(++ for Solr etc etc) from ARQ.
Do you want to organise this as a separate LARQ component in JIRA?
Makes sense to me to have a separate tag if it's a separate code module.
On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
> LARQ as a separate module from ARQ
> ----------------------------------
>
> Key: JENA-9
> URL: https://issues.apache.org/jira/browse/JENA-9
> Project: Jena
> Issue Type: Test
> Components: ARQ
> Reporter: Paolo Castagna
> Priority: Minor
>
>
> LARQ can be extracted from ARQ as a separate module depending on ARQ.
>
> ARQ should not depend on LARQ (to avoid dependency cycles) and it
could check if LARQ is available in the classpath and wire the property
function in dynamically.
>
> LARQ can have a different release cycle from ARQ and people who do
not need free text search will not need to include Lucene in their
classpath.
>
> A separate (experimental) module is available here:
https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
>
> List of things to do/decide includes:
>
> - Merge JENA-5 fix
> - Upgrade Lucene version to 2.9.3 and fix tests (if there are
failures).
> - Remove code using deprecated Lucene APIs and upgrade to Lucene 3.0.x.
> - Decide how many results to return when the user does not specify
it, 1000? More?
> - Should we use the index to suppress duplicates instead of
in-memory data structures?
> - How do we implement removals/unindex?
> - We could use the Model to decide when there are no more
triples with a specified literal and therefore it's ok to remove it from
Lucene.
> - See how the new NRT capabilities of Lucene can be used from LARQ.
> - Review package names (currently c.h.h.j.sparql.larq and
c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
No rush here IMO, depending any bigger repackagization.
Andy
On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
LARQ as a separate module from ARQ
----------------------------------
Key: JENA-9
URL: https://issues.apache.org/jira/browse/JENA-9
Project: Jena
Issue Type: Test
Components: ARQ
Reporter: Paolo Castagna
Priority: Minor
LARQ can be extracted from ARQ as a separate module depending on ARQ.
ARQ should not depend on LARQ (to avoid dependency cycles) and it could check
if LARQ is available in the classpath and wire the property function in
dynamically.
LARQ can have a different release cycle from ARQ and people who do not need
free text search will not need to include Lucene in their classpath.
A separate (experimental) module is available here:
https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
List of things to do/decide includes:
- Merge JENA-5 fix
- Upgrade Lucene version to 2.9.3 and fix tests (if there are failures).
- Remove code using deprecated Lucene APIs and upgrade to Lucene 3.0.x.
- Decide how many results to return when the user does not specify it, 1000?
More?
- Should we use the index to suppress duplicates instead of in-memory data
structures?
- How do we implement removals/unindex?
- We could use the Model to decide when there are no more triples with a
specified literal and therefore it's ok to remove it from Lucene.
- See how the new NRT capabilities of Lucene can be used from LARQ.
- Review package names (currently c.h.h.j.sparql.larq and
c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
