java 8 changes the order of results returned by a hash map. I don't think this impacts us, though -- while they shouldn't -- some tests may depend on the order.
On Wed, Apr 22, 2015 at 5:14 PM, Andy Seaborne <[email protected]> wrote: > On 22/04/15 11:12, Claude Warren wrote: > >> +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). >> > > Java8 looks like an interesting one. The version cycle is supposed to > become a regular 2y cycle IIRC. > > If necessary, to advance strict RDF 1.1, we could have 2.14.0 but I hope > we don't need to. > > Andy > > > >> Claude >> >> On Wed, Apr 22, 2015 at 4:30 AM, Bruno P. Kinoshita <[email protected]> >> 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 <[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 >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
