Henry,
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.
Andy
---------------------------------
[1] http://incubator.apache.org/guides/mentor.html#repackaging
Details:
http://bit.ly/l4f5tE
1/ Import
Copy Jena-CVS, Jena-SVN, Joseki-CVS into Apache SVN as
/import/jena-cvs
/import/jena-svn
/import/joseki-cvs
Hopefully with history, but otherwise, tarballs including history. We
must have a public record of the imported code.
infra has to do the import.
[**Done]
2/ Working set
Pull out modules from the import (leaves the import as an unchanging
public record).
Modules:
/Jena2/jena
/Jena2/iri
... ARQ, SDB, TDB, Fuseki, Joseki, Eyeball
[**Done]
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, ....)
website
5/ Technical changes
==> Jena 3
http://bit.ly/l4f5tE
==
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201105.mbox/%[email protected]%3E
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<[email protected]> 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
<[email protected]> wrote:
Process documented:
http://seaborne.blogspot.com/2011/05/importing-sourceforge-code-into-apache.html
Andy
