> 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 <[email protected]>
To: [email protected]
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 <[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
>
>
>
>
>
