incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Code import
Date Sat, 11 Jun 2011 16:49:18 GMT

The imported code is exactly as from SourceForge.  We're leaving that as 
a complete public record of the starting point in Apache.  From this, 
code has been pulled out (svn copy) to form the working set under 
svn:Jena2/  This starts from com.hp.

The plan is that next we get a proper Apache release setup which is 
compatible with Jena-before-Apache. At this point, users (people and 
organisations) can start to get the code from the new places, with the 
new license.

A consequence of that compatibility is retaining the package names and 
we are using point Benson makes that renaming is not required [1].  We 
also have various vocabularies we need to migrate to a new HTTP host.

The general feeling is that we will rename packages at a suitable point. 
  Obviously, that's an incompatible change and one we need to consider 
carefully how to handle the transition in terms of timing and to help 
smooth changes.

We know that from the previous "big bang" change that code using the old 
naming will continue to be used for quite sometime, and nowadays there 
are more many user than the Jena1->Jena2 transition.  For many of the 
users POV, there is little value in the change, just re-qualification costs.

We are discussing how and when to make incompatible changes.  The 
general feeling is, on balance, to rename packages.  We want to have one 
incompatibility change point so it's a chance to do some clearing up, 
remove deprecated code etc etc.  Hopefully, some compatible naming code 
can also be provided (I haven't checked this works BTW and whether any 
Java-isms will block or make it costly).

LARQ, the Lucene-based free-text indexing for SPARQL, split out from ARQ 
(the query engine) has org.apache.jena package names already.  This is 
our most advanced area for changes to the Apache process.

Any advice and experience you can provide in managing this miogration 
would be greatly appreciated.




1/ Import

Copy Jena-CVS, Jena-SVN, Joseki-CVS into Apache SVN  as


Hopefully with history, but otherwise, tarballs including history.  We
must have a public record of the imported code.

infra has to do the import.


2/ Working set

Pull out modules from the import (leaves the import as an unchanging 
public record).

... ARQ, SDB, TDB, Fuseki, Joseki, Eyeball


3/ Build

[**we are here]

Start to make the build Apache-compatible.
Use the current independent set of builds.

==> Jena 2.7

4/ Restructure

Reorganise into a integrated build system.
   code projects, dependency linked.
   multiple build artifacts (distribution, ogsi, one-jar, war, ....)

5/ Technical changes

==> Jena 3

On 11/06/11 01:21, Benson Margulies wrote:
> It's not required. The project can decide for itself when or if to
> impose this inconvenience on the users.
> On Fri, Jun 10, 2011 at 8:14 PM, Henry Saputra<>  wrote:
>> Hi Andy,
>> Currently I think there are code that still uses com.hp.* as package,
>> I believe this needs to be moved/rename to org.apache?
>> - Henry
>> On Thu, May 19, 2011 at 7:16 AM, Andy Seaborne
>> <>  wrote:
>>> Process documented:
>>>         Andy

View raw message