That would not be ideal unless you have the process scripted. I don't
want to create rework.
Actually that might help. In the first commits I was still just getting my
feet wet and understanding the current test harness, but now I already
would have to review some of my previous commits.
I've found a few patterns that I would like to document, e.g. the
TestPackage suite found in the core module, some test suite classes being
prefixed with TS_, and easy ways to convert several classes at once by
starting by a parent class like JenaTestBase.
I'd prefer that you worked on the Jena3 branch, told me if there was any
testing or anything else that I could do to help, and then once it has been
merged into master, I would restart the work on JENA-380.
Side note: The only scripting that I have in place for now, is some shell
scripting (grep, find, etc) to find classes that have to be ported. But I
would like to run some other code/script in the future that could find the
following: "Classes under the src/main/test directory, with a public method
which name starts with test, has no parameters and doesn't contain the
@Test annotation". I missed to annotate a few JUnit3 test methods, and a
script like that could help me to review my changes before committing the
code. Is anybody aware of how to do that in a simple and quick way? I know
that is doable with some reflection and Java code, but if there was a
simple Groovy script, sed/awk/regexes shell, or something easy to run, that
would be very helpful too.
Anything I can do to help?
Reviewing and testing my changes later would be grand!
I'll use SonarQube and Surefire reports to count the number of tests and
the coverage before and after the changes in JENA-380. But since the
changes in JENA-380 will be orthogonal, involving several modules (in
special core, iri and arq), the more eyes we can get to review and make
sure that no tests have been disabled or broken, the merrier.
If you, Rob, Claude, and all, could inspect modules that you are familiar
with, and tell me if the tests seem to be working correctly, that would be
of great help. How does that sound?
ThanksBruno
From: Andy Seaborne <a...@apache.org>
To: dev@jena.apache.org
Sent: Wednesday, April 22, 2015 10:43 AM
Subject: Re: Start Jena3
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 <a...@apache.org>
To: dev@jena.apache.org
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
