Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Message-ID: <28284914.267971293027422285.JavaMail.jira@thor>
Date: Wed, 22 Dec 2010 09:17:02 -0500 (EST)
From: "Andy Seaborne (JIRA)" <jira@apache.org>
To: jena-dev@incubator.apache.org
Subject: [jira] Commented: (JENA-9) LARQ as a separate module from ARQ
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JENA-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974208#action_12974208 ] 

Andy Seaborne commented on JENA-9:
----------------------------------

>> 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.*?
> I think we should, but I have not done it yet.
> Indeed, we could change to org.apache.jena.larq.*. What do you think? 

OK - for LARQ, because it's new. The renaming existing APIs in Jena and ARQ needs to be co-ordinated and we need to discuss the migration strategy.  There is no rush to do it - not until we have the codebase cleared for all legal issues.


> LARQ as a separate module from ARQ
> ----------------------------------
>
>                 Key: JENA-9
>                 URL: https://issues.apache.org/jira/browse/JENA-9
>             Project: Jena
>          Issue Type: Task
>          Components: LARQ
>            Reporter: Paolo Castagna
>            Assignee: Paolo Castagna
>
> 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.*?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.