- downloaded binary tarball and checked md5 & sha1 sums - unpacked, ran MeetingDetector as in README section 3.4 - also deployed with deployAsyncService and ran runRemoteAsyncAE from another node - installed in DUCC and ran a long test with 5 DUCC jobs using 3 UIMA-AS services. - verified that it rejects an older core UIMA (2.8.1) * README has redundant lines describing the version checker in What's New - spot-checked licenses and notices - downloaded source and checked md5 & sha1 sums - unpacked & built from source & checked md5 & sha1 sums - unpacked that build and ran MeetingDetector
+1 OK to release On Wed, Dec 14, 2016 at 1:52 PM, Marshall Schor <[email protected]> wrote: > Hi, > > These tests run dd2spring against a large number of variants, and then > compare > what gets produced against a set of expected values. The expected values > are > files under the folder uima-as/src/test/resources/deploy/expected. > > I got things running again, with the following "scaffolding": > > 1) I removed the call in Dd2SpringTest.java where it was setting a test > mode > (the test mode was removed as described above). This let the test driver > run. > > 2) I changed dd2spring.xslt **temporarily** to **not** terminate on first > error. This is because the tests sometimes expect to get errors, and the > termination results in further tests never being run. > > After doing that, I ran the test, and got many comparison failures. These > (I > think) are all expected, due to changes made to dd2spring since Feb 2015, > when > this test was last run... > > For each failure, I updated the expected results, finally ending up with a > successful run. The updates I made were: > > 1) change the dtd from dtd/spring-beans to dtd/spring-beans-2.0. > > 2) change singleton="true" to scope="singleton". > > 3) change singleton="false" to scope="prototype". > > 4) remove the singleton flag from beans implementing > AsynchAECasManager_impl > > 5) remove the singleton flag from beans implementing java.util.HashMap > > =============== > > Jerry - do all of these changes seem OK to you based on changes you've > done to > dd2spring? > > =============== > > -Marshall > > > > Jerry - can you confirm these are expected (OK) changes? > > 1) The dtd changed from ..dtd/spring-beans.dtd"> to > dtd/spring-beans-2.0.dtd"> > > 2) The way scope was set to singleton changed from singleton="true" to > scope="singleton" > > 3) The def for AsynchAECasManager_impl bean was changed from > <bean id="casManager" class="org.apache.uima.aae.AsynchAECasManager_impl" > singleton="true"> > to > <bean id="casManager" class="org.apache.uima.aae.AsynchAECasManager_impl"> > for some of the tests: > defaultingPrimAEMultiInstance, > defaultingAENoBroker, > tempQ1, > defaultingAE > > 4) the def for error.Threshold bean changed by dropping the > singleton="true" for > 4 tests, > sometimes only on one of the 2 beans defined (the other still must have the > singleton="true" > defaultingPrimAEMultiInstance, > defaultingAENoBroker, > tempQ1, > defaultingAE > > 5) change bean def for TempDestinationResolver from singleton="false" to > scope="prototype" in tempQ1 test > 6) change bean def for java.util.HashMap - drop the singleton > On 12/9/2016 11:21 AM, Marshall Schor wrote: > > if, after fixing, the dd2spring tests are ok, then, no... not a blocker. > > > > This is what I would expect. > > > > > > On the other hand, if there are are (new) bugs discovered in dd2spring, > it would > > depend if the bugs were "impactful"... > > or just cosmetic... > > > > -M > > > > On 12/9/2016 10:16 AM, Jaroslaw Cwiklik wrote: > >> I never run this test. Buried in a place I did not expect a junit test. > >> Since this is broken, are you inclined to vote the RC2 down? > >> -jerry > >> > >> On Fri, Dec 9, 2016 at 9:47 AM, Marshall Schor <[email protected]> wrote: > >> > >>> These are the tests for dd2spring transform xslt code. > >>> > >>> They make use of the src/main/test/resources, also kept in this > project. > >>> > >>> They could be moved, because these tests are testing artifacts whose > >>> source are > >>> in this project (dd2spring script). > >>> > >>> I think these were always run "by hand" (in Eclipse, right click the > >>> src/test/java folder and pick Run As junit test), whenever dd2spring > >>> changed. > >>> > >>> I traced the reason this compile error is occurring by looking at the > SVN > >>> history of Dd2spring java source. There was a new "test mode" added to > >>> dd2spring back in 4 Feb 2015 (rev 1657361), which had this > "setTestMode()" > >>> method. That was removed from dd2spring, breaking this test, on 21 > July > >>> 2016, > >>> revision 1753681, perhaps accidentally. > >>> > >>> As I recall, the reason these tests were run manually was because they > are > >>> thrown-together tests (better than nothing) that are rather fragile in > how > >>> they > >>> compare results. (probably needs the new xml compare utility to avoid > >>> spurious > >>> complaints for instance due to <xyz></xyz> not comparing equal with > >>> <xyz/>). > >>> > >>> -Marshall > >>> > >>> On 12/9/2016 9:14 AM, Jaroslaw Cwiklik wrote: > >>>> Isn't this an odd place for a Junit test code? This fell off my radar > >>>> completely buried in this location. Don't recall placing this there. > >>> Seems > >>>> like this belongs to uimaj-as-activemq project where the rest of junit > >>>> tests for uima-as "live". What was the motivation to place this code > in > >>> its > >>>> current location? This seems like dead code to me. Dead meaning not > being > >>>> used. > >>>> > >>>> -jerry > >>>> > >>>> On Thu, Dec 8, 2016 at 4:17 PM, Marshall Schor <[email protected]> wrote: > >>>> > >>>>> In project uima-as, > >>>>> in the src/test/java, > >>>>> in the method org.apache.uima.as.dd, > >>>>> in the class Dd2SpringTest, there's a line: > >>>>> dd2SpringInstance.setTestMode(); // prevents throwing on > >>> errors > >>>>> which Eclipse flags as an error, because there is no "setTestMode()" > >>>>> method in > >>>>> Dd2SpringInstance. > >>>>> > >>>>> The normal maven build doesn't catch this because the project > "uima-as" > >>> is > >>>>> not a > >>>>> configured as a Java project, > >>>>> so no compile of the src/test/java classes happens. > >>>>> > >>>>> Is this expected? > >>>>> > >>>>> -Marshall > >>>>> > > > >
