Jena 2.13.0 has been out for out for a few weeks now and nothing too bad
has happened (yet ... :-).
So let's start Jena3!
Summary:
Please +1 if the process and timescale below works for you.
(If I don't hear to the contrary I'll start the process later this week.)
-------------------------------
Knowing there is some in-progress changes in various places, I wanted to
confirm with everyone that now is good time, especially JENA-380.
If the timescale is inconvenient, do say so now.
The timescale isn't driven by external needs so it's flexible.
Proposed detailed process for the first steps.
A/ Tag master with "jena-2-3-split"
B/ Create remote branch jena3
Create remote branch jena2
Branch "jena3" is short-term, just to get the first steps sorted out and
reviewed, i.e. preparation for (1). It quickly becomes "master".
C/ Do step 3 : Rename com.hp.hpl.jena packages to org.apache.jena
That is, package trees:
jena-sdb/src/test/java/com/hp/hpl/jena
jena-sdb/src/main/java/com/hp/hpl/jena
jena-core/src/test/java/com/hp/hpl/jena
jena-core/src/main/java/com/hp/hpl/jena
jena-arq/src/test/java/com/hp/hpl/jena
jena-arq/src/main/java/com/hp/hpl/jena
jena-tdb/src/test/java/com/hp/hpl/jena
jena-tdb/src/main/java/com/hp/hpl/jena
I've just trialled this for the codebase and it is scarily easy to do
with Eclipse.
D/ Get the build working.
Lots of POM updates to do but I have a build that builds.
(this isn't everything - it leaves scripts, logging settings and
resources to be done)
E/ Check and review
Is 24 hours enough here?
I want to keep the window between (C) and (F) small to cope with changes
during that window.
F/ When confirmed:
merge jena3 into master and push
If the merge does not work, delete master, and rename jena3 to master.
At this point master is jena3 and there is a jena2 branch.
G/ delete jena3 branch.
H/ Documentation/website
There are quite a few choices in the details - improvements welcome.
Experience doubly welcome. I've not done something as repo-wide as this
before.
Andy
learnings for migration:
L1/ Assembler files have class loading in them especially
com.hpl.hpl.jena.tdb. Maybe worth trapping during loading and changing
to org.apache.jena.tdb.
L2/ "java:" custom filter functions (ARQ and Leviathan). Again, add
transition to the loading step.
L3/ slf4j/log4j : logger names
L4/ Can collapse some module versions to track 3.0.0 (jena-text,
jena-spatial ...)
On 24/01/15 18:33, Andy Seaborne wrote:
Here is a suggestion for Jena3.
After 2.12.2 or 2.12.3,
1/ A branch for Jena2 ; master is Jena3.
2/ Switch to RDF 1.1 setting for strings
3/ Rename com.hp.hpl.jena packages to org.apache.jena
4/ Other changes
5/ Let things settle down.
6/ Release (beta? just go for it as 3.0.0?)
(3) is the disruptive step - I doubt git merge is going to be much help
after that for managing changes related to com.hp.hpl.jena packages
I wrote some migration notes for the RDF 1.1 isms and packages.
http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html
There is a lot of things that could be done. I like us to avoid
over-committing ourselves. The question I have is what is *necessary*
to drive into jena 3.first.
Andy
