This also sounds like something that could nicely be Maven-ized into an HTML table.
Gary > -----Original Message----- > From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 10:49 > To: Jakarta Commons Developers List > Subject: Re: [lang][codec] Sanity checking a client project build > > I agree with the idea about testing all Java versions. Testing all > platforms is important too. In theory, it seems like we need some type > of text matrix, in which we identify all platforms and JREs that the > software has been tested on. > > Something like: > > 1.2 1.3 1.4 > Solaris x > Linux x x x > Windows x > BSD x x > Mac OSX x x > > Even if we are not able to access every version on every platform, it > would be nice to see this information. Users who have access to an > untested platform could volunteer to run the tests and submit the results. > > Is this overkill? > > > > > Gary Gregory wrote: > > I agree with all of your responses, I was being a bit paranoid ;-) > > > > What about Java versions: 1.2 vs 1.3 vs 1.4? Hopefully a released > component > > has been tested on all. Perhaps this should be part of the release > > procedure: "Make sure the build runs on JDK a, b, and c". I am not sure > we > > have such a guarantee, at least it is not advertised in the release > notes or > > on the web presence for a component: "These unit tests pass on JRE a, b, > and > > c"-type of statement. Sometimes we catch a 1.4 API call in [lang] and we > > clean that up, good. But what about 1.3 vs 1.2? Far fetched perhaps but > it > > would be good to know for sure. > > > > Thanks for your patience, :-) > > Gary > > > > > >>-----Original Message----- > >>From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > >>Sent: Friday, November 21, 2003 09:46 > >>To: Jakarta Commons Developers List > >>Subject: Re: [lang][codec] Sanity checking a client project build > >> > >>You're definitely not nuts, but perhaps a little paranoid ;). > >> > >> From what I've seen, it seems to be a prereq of any released commons > >>component that ALL unit tests must pass. This is one of the reasons > >>that I've never had a doubt about creating a dependency on any project > >>from commons. > >> > >>So, while invoking these tests from your own project does seem safe, it > >>also seems unnecessary. The [lang] developers (which of course includes > >>you) are already ensuring that all of the tests pass and that the code > >>is solid. > >> > >>Now if you're depending on the CVS HEAD, that's a different story. But > >>even in that case, running the tests whenever you do a cvs update seems > >>to be enough. > >> > >>Although, releasing a unit test jar is an interesting idea. > >> > >>Summary: A released version of any project passes all tests. Why create > >>the extra work for yourself? > >> > >> > >> > >> > >>Gary Gregory wrote: > >> > >>>Hello, > >>> > >>>I'll start this topic on [lang] and [codec] only since I am active > here. > >>> > >>>I am considering adding to the unit test suite of /my/ project the unit > >>>tests of 3rd party libraries. Why do this? As a simple sanity check. > Our > >>>project uses [lang], [codec], [pool], [cli], [collections], Xerces, > >> > >>Xalan. I > >> > >>>would like the confidence added to /my/ project, that all of these > >> > >>pieces > >> > >>>are working as advertised and that no side effects exists. > >>> > >>>This is why I would like to suggest that [lang] and [codec] deliver > >> > >>their > >> > >>>unit tests in jar files instead of plain source. > >>> > >>>A secondary point I have not thought through is how do you know which > >> > >>tests > >> > >>>to invoke. The build.xml file contains a test target which I could > >> > >>invoke > >> > >>>from my build file but I like to use the Ant/Junit reporting feature. I > >> > >>do > >> > >>>not want to impose this requirement on the build.xml file for a project > >> > >>of > >> > >>>course. > >>> > >>>Any thought? Am I nuts? Paranoid? > >>> > >>>Thanks, > >>>Gary > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
