+1 for the change to Jena3 The timeline looks ok to me.
I like the idea of holding onto jena2 for awhile in case of emergencies. As for the testing..... I think it is best to restart JENA-380 after the switch to jena3. This would effectively make JENA-380 both the conversion to Junit4 and the verification that we have all the tests we think we do . (I am assuming here that we do as Bruno suggests and each inspect the tests for the modules we are most familure with). Claude On Wed, Apr 22, 2015 at 4:30 AM, Bruno P. Kinoshita <ki...@apache.org> wrote: > > 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 > > > > > > > > > > > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
