jtreg testing integrated
Andrew John Hughes
gnu_andrew at member.fsf.org
Wed May 21 17:02:25 PDT 2008
> > I mention this because I think the
> > term could be a little disparaging to outsiders, as it implies only a
> > build with proprietary Sun code is considered production ready.
> Yes, getting accurate, descriptive, and neutral (and concise) wording can
> be tricky, as "proprietary" is also disparaging in some contexts ;-)
Er... it's very much intended to be disparaging. There's a good basis
for that, whereas I don't see one for simply classifying all other
builds as below the standard of this 'production build' -- well,
outside Sun anyway :)
> > I wouldn't add any code to rely on the name of a build from the GPLed
> > code. It's just asking for trouble further down the line. Besides,
> > by including such tests, you're effectively wrongly favouring some
> > GPLed distributions over others.
> Well, the tests in question come with the code, both under GPL, so if
> someone wanted to have java.runtime.name=Fred for some reason, the tests in
> question could be updated to expect "Fred" instead.
I must be missing something but I don't see why:
is a problem, given its the proprietary build that needs a special
case. Otherwise you're inconveniencing every other build for the sake
> > Is a test for the production system (with an appropriate comment so we
> > know that's what it is) not sufficient?
> That is probably sufficient for the cases in question.
> There are really three cases of possible interest: Sun's traditional
> (proprietary) product bits, a "usual" OpenJDK build, and something else. A
> "usual" OpenJDK build perhaps is something yet to come about; I'm thinking
> there may be conventions we all choose to follow as good practices that may
> affect how the tests are written in some way. A "something else" build
> would, say, be based on the OpenJDK code, but choose to go against usual
> practice in some manner.
> The cases currently under consideration just need to make a decision based
> on "Sun's traditional (proprietary) product" versus "not Sun's traditional
> (proprietary) product."
Ah that seems to agree with what I said above :)
> > > and production JDK) fail else note/warning" logic so that our production
> > > build gets the same coverage and if an OpenJDK build come with a
> > > engine, it would get testing too.
> > >
> > >
> > Wouldn't testing the result of
> > ScriptEngineManager.getEngineFactories() suffice? Why do
> you need to
> > specifically test for a production build?
> this is *not* required by the specification. The OpenJDK sources do not
> should be tested the same way, but not having the engine shouldn't be fatal.
> This would preserve the same degree of testing of the product bits, allow
> the tests to pass out of the box for an OpenJDK build, and perform the same
> tests for an OpenJDK build if an engine happens to be present.
So I see two things to test for in that case:
2. Do we require one as part of this test run?
The latter could be a property, which would be set for a proprietary
build and any other where someone wants to require that a JS
implementation is provided.
I guess a similar case will be needed for SNMP.
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev