[icedtea-web] RFC: add unit tests for the jnlp parser

[Omair Majid]

On 03/30/2011 12:21 PM, Dr Andrew John Hughes wrote:
> On 12:49 Fri 25 Mar     , Omair Majid wrote:
>
> snip...
>
>>> >  >
>>> >  >  I seem to recall that there was an option to alter JUnit output by implementing
>>> >  >  some class but my information is pretty out of date.
>>> >  >
>> >
>> >  That's pretty much what I needed up doing. The only problem is
>> >  licensing. What license is that code under? JUnit is under Common Public
>> >  License and my custom code (attached) includes a few lines from JUnit
>> >  itself.
>> >
> Oh, something that still uses CPL.
>
> There is a brief summary on Wikipedia:https://secure.wikimedia.org/wikipedia/en/wiki/Common_Public_License
>
> Basically, it's the predecessor to EPL, the license Eclipse is under.
>
> IANAL, but I don't see the problem with this.  The code is independent
> from everything else in the codebase, isn't it?  So GPL
> incompatibility isn't an issue (and we have the Classpath exception
> anyway).  And it's a FOSS license so we can certainly include the
> code.
>

Ah, ok. I thought we wanted to only include code which is GPL-friendly 
in IcedTea. If we are ok with adding independent code under other 
license, it certainly makes this a non-issue.

> What JUnit code is included?  Is it marked?
>

Please see the attached patch. I havent marked it, but almost all the 
code in CommandLine.java is based on JUnit code. The 
LessVerboseTextListener.java implements JUnit interfaces, but it is 
written from scratch.

>>> >  >  One option to consider is Mauve.  If we reused its test harness, any
>>> >  >  improvements would also feed back to that project and benefit us with
>>> >  >  JDK testing too.  The downside is that it isn't packaged, but I think
>>> >  >  it's small enough that we could bring it into the IcedTea-Web tree.
>>> >  >  Long-term, we could separate the harness itself out and use it with
>>> >  >  both IcedTea-Web and Mauve.
>>> >  >
>> >
>> >  Using mauve would make it harder for new developers to contribute. Not
>> >  to mention that testing frameworks like JUnit and TestNG have much
>> >  better IDE integration.
>> >
> I didn't know IDE integration was a required feature, but you make a fair point.

I wouldn't call it required, but I think it makes it much easier to 
write/run tests for those of us who use IDEs.

> I guess it was a bad suggestion.  I have the ulterior motive of
> wanting to drive some work on Mauve.  It's a good test suite and one
> which is used by a variety of projects, unlike the OpenJDK JTreg tests
> which tend to be tightly attached to OpenJDK, both physically (files
> in the same repo) and in the code, via reliance on HotSpot features
> and internal classes.  Plus, it's a lot easier to get running than the
> mess we currently have with JTreg.
>

Not a fan of JTreg myself.

>> >  I would like to see less things in-tree (/me is looking at NanoXML), not
>> >  more.
>> >
> How is the NanoXML issue progressing?  It would be good to have a status update
> on things and the progress towards the various releases of IcedTea-Web now 1.0
> is done.
>

Sorry, I must have forgotten to make a note of this. Generally I try and 
keep http://icedtea.classpath.org/wiki/IcedTea-Web#Release_Plans 
updated. Anyway, it's mostly done. I wrote these parser unit tests to 
test that my NanoXML changes did not break anything. I will clean up 
that patch and post it after these unit tests are committed (so we can 
see any regressions). Assuming Deepak is fine with it, it can go in 
before 1.1 is released.

>>>> >  >>  I can work around it by writing a front end to it (already done, but I
>>>> >  >>  am not sure about the licensing here), or using something like ant to
>>>> >  >>  generate xml output which can be transformed (similar to how I have done
>>>> >  >>  it for testng) to text.
>>>> >  >>
>>> >  >
>>> >  >  Why is ant needed?   Please, no:-)
>>> >  >
>> >
>> >  If we want to avoid modifying junit and still want xml reports, it is
>> >  probably the only sane option.
>> >
> I really don't get want ant has to do with XML, given the XML APIs are in
> the JDK.  If it's ant vs. these other dependencies for testng, I'd choose
> the latter but that's a choice between a rock and a hard place, really.
>

I should have elaborated more. JUnit/TestNG (and possibly others) are 
just fine for developers. The problem here is that we want to generate 
buildbot-readable test results. We can do that by writing a custom 
junit-output formatter (like in the attached patch), by transforming 
testng's xml output or by transforming junit's xml output. Unfortunately 
the only way of getting junit to create xml output is through ant. Junit 
itself has no option (at least nothing that I could see) that generates 
output in xml format. If it is okay to use the custom junit output 
formatter, than we dont need ant. Actually, if we dont care about the 
buildbot, then we dont need the custom output formatter or any xml 
processing at all.

> Ant massively overcomplicates things, but I have no idea of the availability
> of the various dependencies for testng or their licenses.
>
> Can you provide some of this info?
>

Sure. TestNG is licensed under Apache 2.0. Its dependencies are QDox 
(Apache 2.0) and Bean Shell (Sun Public License or LGPL).

TestNG (and its dependencies) are available in a number of Linux 
distributions, including Debian (squeeze, wheezy and sid), Fedora (>= 
13), Gentoo (java-experimental overlay), Mageia, Mandriva (, openSUSE 
(>= 11.2), and Ubuntu (>= 9.10). It's not available in Arch Linux, and 
Slackware (and possibly other distributions).

JUnit is licensed under Common Public License v.10.

JUnit is available in all the distributions listed above - including 
Arch Linux and Slackware.

>> >  My custom runner:
>> >  Passed: net.sourceforge.jnlp.ParserBasic.testResourcesJar
>> >  Passed: net.sourceforge.jnlp.ParserBasic.testResourcesExtensions
>> >  Passed: net.sourceforge.jnlp.ParserBasic.testResourcesProperty
>> >  [snip]
>> >  FAILED: testUnquotedAttributes(net.sourceforge.jnlp.ParserMalformedXml)
>> >  Invalid XML document syntax.
>> >  Test results: passed: 23; failed: 4; ignored: 0
>> >
>> >  I suppose using plain JUnit is fine; it just wont have pretty output
>> >  suitable for buildbot.
>> >
> The custom runner looks fine.  What's the problem?
>

Other than my licensing concerns (CPL in a GPL-friendly repository), 
nothing.

Thanks,
Omair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: junit-runner.patch
Type: text/x-patch
Size: 3243 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110330/6c8be0c3/junit-runner.patch