jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <andy.seabo...@epimorphics.com>
Subject Re: [jira] Created: (JENA-9) LARQ as a separate module from ARQ
Date Tue, 14 Dec 2010 20:14:09 GMT
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.*?
>
>

Mime
View raw message