commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang][codec] Sanity checking a client project build
Date Fri, 21 Nov 2003 20:03:33 GMT
This also sounds like something that could nicely be Maven-ized into an HTML
table.

Gary

> -----Original Message-----
> From: __matthewHawthorne [mailto:matth@phreaker.net]
> 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:matth@phreaker.net]
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message