On 21/04/15 23:14, Bruno P. Kinoshita wrote:
Hi Andy!
When are you planning to start work on Jena3?
Later this week but it's for discussion and flexible.
The basic setup, the disruptive bit should be over in a few days (famous
last words!) to leave a rough, buildable setup.
Knowing there is some in-progress changes in various places, I wanted to
confirm with everyone that now is good time, especially JENA-380.
I started to grok how to migrate JUnit3 tests to JUnit4, and have committed
some code to the JENA-380 branch. But it wouldn't be a problem to start from
scratch after Jena3 branch has been merged into master. It would probably take
a couple of weeks to have something that could be merged back into master.
That would not be ideal unless you have the process scripted. I don't
want to create rework.
If we postpone JENA-380, in the meantime I could:
a) observe the commit log and get used to the new project structure
> b) document in the Jira issue (and/or site or Wiki) how the tests are
being migrated (e.g. remove old junit.framework.* imports when
appropriate, replace TestSuite's by @RunWith and @SuiteClasses, etc). So
that if any test is broken later it is easier to understand what might
have happened
c) update the JENA-632 branch code
d) learn more about Claude's junit-contracts project
e) help testing parts of the code migrated?
What do you think?
Is there an intermediate point that can be merged into master even if
some tests are commented out/@Ignore'd temporarily?
Anything I can do to help?
The rename is in bulk, practical terms ::
s/package com.hp.hpl.jena/package org.apache.jena/g + mv files
s/import com.hp.hpl.jena/import org.apache.jena/g
Or what about putting the upgraded tests into their own package tree
like "org.apache.jena.tests380" in master, not active so don't need to
run, just to compile, and they get updated by Eclipse renames.
On JENA-632 - I'm aware that the GSoC JENA-491 (if approved) are close
to each other, but not clashing, in the grammar.
Andy
Full list of branches:
origin/JENA-380
origin/JENA-507
origin/eliminate-assignments
origin/jena-owl2
origin/streaming-update
Bruno
From: Andy Seaborne <[email protected]>
To: [email protected]
Sent: Wednesday, April 22, 2015 4:28 AM
Subject: Start Jena3
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
