This build has the sources included in the binary distribution. I think we agree to remove this, right?

-Marshall

Michael Baessler wrote:
I have build the next release candidate level for uimaj-2.2.0 (uimaj-2.2.0-RC2). I currently upload the level to people.a.o. (finished in about 30 minutes)
The level will be available at /home/mbaessler/distributions.

I also uploaded the RAT reports with some comments... please have a look.

The level contains the following JIRA issues:
https://issues.apache.org/jira/browse/UIMA-500 : [#UIMA-500] Reduce excessive synch lock contention caused by calls to ll_isValidTypeCode that are not needed - ASF JIRA https://issues.apache.org/jira/browse/UIMA-473 : [#UIMA-473] Update README and RELEASE_NOTES - ASF JIRA https://issues.apache.org/jira/browse/UIMA-465 : [#UIMA-465] Need getViewIterator() method to work with a variable number of views - ASF JIRA https://issues.apache.org/jira/browse/UIMA-507 : [#UIMA-507] Remove ref to gutenberg.org to avoid licensing entanglement possibility - ASF JIRA https://issues.apache.org/jira/browse/UIMA-494 : [#UIMA-494] AnalysisEngineDescription_impl indirectly uses promletatic method URL.equals() - ASF JIRA https://issues.apache.org/jira/browse/UIMA-508 : [#UIMA-508] Docbook build tool - not updating the olink databases unless running the full 4-book build - ASF JIRA https://issues.apache.org/jira/browse/UIMA-492 : [#UIMA-492] uimaj-cpe test failures on some machines when run from maven - ASF JIRA https://issues.apache.org/jira/browse/UIMA-316 : [#UIMA-316] CVD does not display auto-indexes correctly - ASF JIRA https://issues.apache.org/jira/browse/UIMA-499 : [#UIMA-499] Add source jars to binary distribution - ASF JIRA https://issues.apache.org/jira/browse/UIMA-496 : [#UIMA-496] PEAR API does not delete the PEAR ID subdirectory before the new content is installed - ASF JIRA https://issues.apache.org/jira/browse/UIMA-307 : [#UIMA-307] Fix CVD screenshots - ASF JIRA

-- Michael

Marshall Schor wrote:
Michael Baessler wrote:
Hi,

I see Marshall has fixed the RAT issues reported by Thilo and the JIRA bug tracking system says that we have no open issues to fix for uimaj 2.2.

So it seems that we are ready to build the hopefully latest release candidate level.
+1

But what do we do with all the issues that hang around in the "resolved" state. I think the assignee of the defect should verify the resolved issue for the releases 2.1 and 2.2 before we build the next level.
+1
I don't think that we need a new level to resolve these issues, or I'm wrong here?
I agree. The things in the resolved state should be changed to close state (unless the person doing the change has an issue, of course). I went thru the resolved / not closed, and for many where I knew the situation, changed them to closed.
I know Eddie will try and finish up some doc changes today, also.

And we still have some open test cases... I can do some more testing tomorrow, but I cannot do all. So please add you name to the tests that you can look at.
When I took a look, the only open tests were the "migration" tools, and testing the examples - some of which is done. (I also tested the SOAP example - I'll add that.)

So I think we're good to go, once doc updates are in, and that includes perhaps redoing the readme stuff for what's changed to capture the additional Jira items relevant to the 2.2 release.

My plan was to build the uimaj-2.2.0-RC2 when all the tests are executed and all the defects are verified. So that we can just need to do a simple regression test
on this level. Does this sound good to you?
+1

-Marshall






Reply via email to