For [lang] for example, we would have commons-lang-test-1.0.0.jar through commons-lang-test-2.5.0.jar available when a build is run.
The files should really be put up wherever we stash the other deliverables. Since 2.5 is out we cannot (?) add these jar files to it but perhaps this could be done for a 2.5.1 and for certain for 3.0. In the case of [lang] 3.0, since we changed the package name, the tests would not run, but you get the idea. Again, for [lang] we could take the 2.5 tests, clone them and only change package references to point to lang3. That would be a one-time deal when a package name changes. For each test jar, you run all *Test* classes in it (or some suitable configurable pattern) against the current [foo] jar. For future releases, this will be easier using JUnit 4 since JUnit should pick up anything marked with @Test. The test reports will then need to be gathered and added to the reports list. We should see the same Surefire summary and details page like we do now for the current tests, but see one report for each binary compatibility test jar. Can Maven handle that? Gary > -----Original Message----- > From: Henri Yandell [mailto:flame...@gmail.com] > Sent: Monday, April 05, 2010 21:34 > To: Commons Developers List > Subject: Re: [codec][lang] Provide a test jar plus [daemon] > > Would love to see this. > > I'll go and put the historic Lang ones together if you let me know how > you'd like it to look. > > Hen > > On Mon, Apr 5, 2010 at 9:16 AM, Gary Gregory > <ggreg...@seagullsoftware.com> wrote: > > Seeing the discussion about [daemon] and not releasing made me think of > another use for a test jar file. > > > > What I would like to know when evaluating an RC for releasing a maintenance > of a commons component (from x.y.n to x.y.n+1) is that there is 100% binary > compatibility. > > > > As part of the build I would run (at least) the 1.0.2 unit tests against the > 1.0.3 RC. If 100% pass all is well, if not, it is either a bug or a known > acceptable failure fixing a bug and should be documented somehow, probably in > a ticket. > > > > This would mean that a release 1.0.3 RC would include foo-test-1.0.2.jar. > And maybe also foo-test-1.0.0.jar and foo-test-1.0.1.jar, hm... > > > > Thoughts? > > > > Gary Gregory > > Senior Software Engineer > > Seagull Software > > email: ggreg...@seagullsoftware.com > > email: ggreg...@apache.org > > www.seagullsoftware.com > > > > > > From: Gary Gregory > > Sent: Tuesday, March 30, 2010 16:58 > > To: Commons Developers List > > Subject: [codec][lang] Provide a test jar > > > > I am starting with codec and lang since it what I am most interested in > ATM... > > > > I would like to run commons.xxx unit tests as part of my build as a sanity > check when I try out a new combo of JVM, OS, jars, etc. > > > > Right now, I would have to compile the unit tests as part of my build which > is not great. > > > > So, what about providing a commons-codec-1.5-test.jar file like we provide a > sources and javadoc file? > > > > Same for any commons project really... > > > > Thoughts? > > > > Gary Gregory > > Senior Software Engineer > > Seagull Software > > email: ggreg...@seagullsoftware.com > > email: ggreg...@apache.org > > www.seagullsoftware.com > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
