On 18/05/11 10:00, Paolo Castagna wrote:
Andy Seaborne wrote:
We have a gap while code is moved and before we have a
Apache-compliant release process but I think it's a good idea to
minimise the time when we don't have a releasable system.
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.
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
3/ Build
Start to make the build Apache-compatible.
Use the current independent set of builds.
Just to make sure, step 1, 2 and 3 do not require any package renaming
(i.e. com.hp.hpl.* -> org.apache.*). Correct?
Correct.
Should we change the license and headers in the source code as part of
3?
See the process:
http://incubator.apache.org/guides/mentor.html#initial-clean-up
Yes - it's got to be done by my reading.
My objective is minimal project downtime.
Pulling out the projects means we (I have an immediate need here) can
keep working and checking things in. Don't want to stop anyone
completing JIRAs.
We can at least build the old way for snapshots to get the between
project jar exchange working.
Release is needs preparation work - please anyone help.
Jena 2.7 is Jena packaged as-is but released under Apache process. This
will take some understanding and sorting out, but once setup should be
low overhead (:-)
4+5 are user-visable changes.
Andy
I have other questions on 4 and 5, but I'll ask when we get there.
Paolo
==> 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
Repackage
My advocacy would be to also simply and reduce the system.
Andy
