You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2005/09/14 18:50:59 UTC
JUnit license, was: subversion etiquette]
Oh bother, said Pooh.. We'd like to write assertion-based tests. What do
folks think we should do:
o Ask JUnit to license itself under the Apache license.
o Use some other assertion-based test framework. Any suggestions?
-Rick
Re: JUnit license, was: subversion etiquette]
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 14, 2005, at 12:01 PM, Andrew McIntyre wrote:
> That would allow people to write Junit tests, run them concurrently
> with the current tests, and provide feedback in the current
> harness' test output if Junit.
was missing from the classpath. (was missing from the end of my
sentence).
andrew
Re: JUnit license, was: subversion etiquette]
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 14, 2005, at 11:40 AM, Daniel John Debrunner wrote:
> If they are required to be run, then are you providing a single
> command
> that executes both derbyall and the junit tests?
It would be trivial to write a .java test wrapper to the current
harness that runs all the Junit tests, and skips them if them junit
isn't in the classpath. That would allow people to write Junit tests,
run them concurrently with the current tests, and provide feedback in
the current harness' test output if Junit.
Yes, you'd still have to update a master for the test wrapper's
output. But it would be a step in the right direction, I think, and
would at least allow people interested in writing Junit tests to go
ahead and start doing that.
andrew
Re: JUnit license, was: subversion etiquette]
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi David,
I think you're right. In any event, I was hoping to checkin an empty canon.
Cheers,
-Rick
David W. Van Couvering wrote:
>
>
> Rick Hillegas wrote:
>
>> Hi Dan,
>>
>> I was hoping that the first point could be accomplished by some
>> jiggery pokery which ran the compatibility suite under the normal
>> (non-junit) test harness, producing a canon. This wouldn't wrench the
>> existing machinery around too much. However, it would require
>> developers to download the junit jar so that the test class would
>> build and execute...and this may be controversial.
>>
> I don't think that the existing harness *requires* output to a canon,
> does it? I was working on a unit test for exceptions which produced
> no output, and as long as I had an empty master file the test harness
> was satisfied.
>
Re: JUnit license, was: subversion etiquette]
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Rick Hillegas wrote:
> Hi Dan,
>
> I was hoping that the first point could be accomplished by some
> jiggery pokery which ran the compatibility suite under the normal
> (non-junit) test harness, producing a canon. This wouldn't wrench the
> existing machinery around too much. However, it would require
> developers to download the junit jar so that the test class would
> build and execute...and this may be controversial.
>
I don't think that the existing harness *requires* output to a canon,
does it? I was working on a unit test for exceptions which produced no
output, and as long as I had an empty master file the test harness was
satisfied.
Re: JUnit license, was: subversion etiquette]
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dan,
We briefly discussed this compatiblity test suite late last month on a
thread titled "client/server compatibility testing". Here's the essence
of that proposal:
o As part of the checkin barrier, derbyall should just test the
compatibility suite against a Derby client and server running at the
current level on the same jdk version.
o The full set of combinations can be run on a weekly basis by some
authority.
o The full set of combinations should be run as part of the release
barrier.
I was hoping that the first point could be accomplished by some jiggery
pokery which ran the compatibility suite under the normal (non-junit)
test harness, producing a canon. This wouldn't wrench the existing
machinery around too much. However, it would require developers to
download the junit jar so that the test class would build and
execute...and this may be controversial.
The full compatibility suite (run weekly and before releases) would be a
collection of junit test runs--for which no canons would be necessary.
It would run under its own small ant- and junit-based harness with its
own instructions. I don't regard this harness as a permanent fixture. I
am cautiously hopeful that someone will tackle the problem of migrating
our existing tests to JUnit; and when they do, my temporary harness can
be thrown away and the compatiblity suite can be integrated with the
general mechanism. Back in May, an email thread titled "JUnit" discussed
the desirability of migrating our tests to the JUnit framework over
time. You described your experiments with JUnit and seemed hopeful that
this framework would reduce the time it takes to run derbyall.
Other than requiring developers to download the junit jar, I think I am
proposing something fairly modest here. However, the camel's snout would
be in the tent. With JUnit now visible to Derby developers, momentum
might build for someone to attempt the bigger migration. At that point,
we probably would have to iron out a lot of controversial issues.
Please help me understand what issues (besides the junit jar
requirement) you see in this first, smaller proposal to expose an ant-
and junit-based compatibility test suite.
Thanks,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>>Thanks Jean, David, and Francois for your suggestion that I amend
>>BUILDING.txt. Now I'm back to an etiquette question: I'm hoping to check
>>in a JUnit assertion-based test. Since the test needs JUnit to build, my
>>patch will break everyone's build: they will have to download the junit
>>jar themselves. This could annoy a lot of folks. What is the etiquette
>>for breaking the build this way?
>>
>>
>
>I think a vote would be needed to accept the patch.
>
>Currently Derby's testing policy is its own harness, you seem to be
>suggesting some change, but it's not clear what.
>
>What's the expectation here, that these Junit tests need to be run
>before any commit, in addition to derbyall? Or that they are separate
>tests run by those that care to, like the current upgrade tests?
>
>If they are required to be run, then are you providing a single command
>that executes both derbyall and the junit tests?
>
>Dan.
>
>
>
>
Re: JUnit license, was: subversion etiquette]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>
>>Thanks Jean, David, and Francois for your suggestion that I amend
>>BUILDING.txt. Now I'm back to an etiquette question: I'm hoping to check
>>in a JUnit assertion-based test. Since the test needs JUnit to build, my
>>patch will break everyone's build: they will have to download the junit
>>jar themselves. This could annoy a lot of folks. What is the etiquette
>>for breaking the build this way?
Some comparisions ...
Though it doesn't affect the build, derbyall runs tests using IBM's
Univeral JDBC driver if it is in the classpath. If it isn't then the
tests are not run. Thus the download of the driver is optional (as it is
not open source software).
And for the build the OSGi jar file is optional, some folks may not be
happy about having to to register to download it. The class that depends
on it is simply not built if the jar is not there, ensuring the build
does not break or give an error message.
Now for an open source jar, such as Junit, I believe requiring its
download is ok for Derby, as long as the licence is generally
acceptable. Downloading a jar under an open source licence that had a
term than you must give all your money to me, would be acceptable to me,
but probably not to any one else! :-)
Dan.
Re: JUnit license, was: subversion etiquette]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> Thanks Jean, David, and Francois for your suggestion that I amend
> BUILDING.txt. Now I'm back to an etiquette question: I'm hoping to check
> in a JUnit assertion-based test. Since the test needs JUnit to build, my
> patch will break everyone's build: they will have to download the junit
> jar themselves. This could annoy a lot of folks. What is the etiquette
> for breaking the build this way?
I think a vote would be needed to accept the patch.
Currently Derby's testing policy is its own harness, you seem to be
suggesting some change, but it's not clear what.
What's the expectation here, that these Junit tests need to be run
before any commit, in addition to derbyall? Or that they are separate
tests run by those that care to, like the current upgrade tests?
If they are required to be run, then are you providing a single command
that executes both derbyall and the junit tests?
Dan.
Re: JUnit license, was: subversion etiquette]
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks Jean, David, and Francois for your suggestion that I amend
BUILDING.txt. Now I'm back to an etiquette question: I'm hoping to check
in a JUnit assertion-based test. Since the test needs JUnit to build, my
patch will break everyone's build: they will have to download the junit
jar themselves. This could annoy a lot of folks. What is the etiquette
for breaking the build this way?
Thanks,
-Rick
Jean T. Anderson wrote:
> Rick Hillegas wrote:
>
>> Oh bother, said Pooh.. We'd like to write assertion-based tests. What
>> do folks think we should do:
>>
>> o Ask JUnit to license itself under the Apache license.
>>
>> o Use some other assertion-based test framework. Any suggestions?
>>
>
> You can use Junit with no problem at all -- and other Apache projects
> do. You just can't check it into subversion.
>
> The DITA toolkit needed additional handling because we need to check
> some of the files into subversion; we found that just downloading it
> wasn't sufficient for what we needed.
>
> -jean
>
>> -Rick
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: subversion etiquette
>> From:
>> "Jean T. Anderson" <jt...@bristowhill.com>
>> Date:
>> Wed, 14 Sep 2005 09:31:48 -0700
>> To:
>> Derby Development <de...@db.apache.org>
>>
>> To:
>> Derby Development <de...@db.apache.org>
>>
>>
>> Daniel John Debrunner wrote:
>>
>>> Rick Hillegas wrote:
>>>
>>>> Sometime soon I hope to checkin some JUnit-based tests for testing the
>>>> compatibility of our clients and servers. As part of this
>>>> submission, I
>>>> want to checkin the JUnit jar itself (into tools/java alongside the
>>>> other jars). Is it ok for the svn diff to contain a big binary file
>>>> like
>>>> this? Will this annoy/confuse reviewers? Is there a more polite way to
>>>> submit jar files?
>>>
>>>
>>>
>>>
>>> I'm not sure you can check Junit's jar into Apache's subversion
>>> repository due to its licence (CPL 0.5).
>>>
>>> http://junit.sourceforge.net/doc/faq/faq.htm#overview_7
>>
>>
>>
>> Dan is correct; we cannot check CPL-licensed software/files into Apache.
>>
>> For example, we couldn't check DITA Open Toolkit files into the derby
>> svn repository because it is under CPL. We discussed the issue with
>> the DITA OT developers and they additionally released it under the
>> ASL 2 at the end of August.
>>
>> Discussions about various licenses pop up on this list:
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ .
>>
>> -jean
>>
>
Re: JUnit license, was: subversion etiquette]
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Rick Hillegas wrote:
> Oh bother, said Pooh.. We'd like to write assertion-based tests. What do
> folks think we should do:
>
> o Ask JUnit to license itself under the Apache license.
>
> o Use some other assertion-based test framework. Any suggestions?
>
You can use Junit with no problem at all -- and other Apache projects
do. You just can't check it into subversion.
The DITA toolkit needed additional handling because we need to check
some of the files into subversion; we found that just downloading it
wasn't sufficient for what we needed.
-jean
> -Rick
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: subversion etiquette
> From:
> "Jean T. Anderson" <jt...@bristowhill.com>
> Date:
> Wed, 14 Sep 2005 09:31:48 -0700
> To:
> Derby Development <de...@db.apache.org>
>
> To:
> Derby Development <de...@db.apache.org>
>
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>> Sometime soon I hope to checkin some JUnit-based tests for testing the
>>> compatibility of our clients and servers. As part of this submission, I
>>> want to checkin the JUnit jar itself (into tools/java alongside the
>>> other jars). Is it ok for the svn diff to contain a big binary file like
>>> this? Will this annoy/confuse reviewers? Is there a more polite way to
>>> submit jar files?
>>
>>
>>
>> I'm not sure you can check Junit's jar into Apache's subversion
>> repository due to its licence (CPL 0.5).
>>
>> http://junit.sourceforge.net/doc/faq/faq.htm#overview_7
>
>
> Dan is correct; we cannot check CPL-licensed software/files into Apache.
>
> For example, we couldn't check DITA Open Toolkit files into the derby
> svn repository because it is under CPL. We discussed the issue with the
> DITA OT developers and they additionally released it under the ASL 2 at
> the end of August.
>
> Discussions about various licenses pop up on this list:
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ .
>
> -jean
>
Re: JUnit license, was: subversion etiquette]
Posted by Francois Orsini <fr...@gmail.com>.
Apache Cactus which is a jUnit-based server test framework, bundles some
version of junit.jar as part of the binaries download. However, junit.jat is
*not* included in the source tree. FYI.
Re: JUnit license, was: subversion etiquette]
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
You're sounding more like Eeyore than Pooh :) As I understand it, we
just can't check it into our repository. We can add instructions into
BUILDING.txt that the developer download JUnit X.X. Just like with the
docs, the doc folks use DITA by downloading it by themselves.
David
Rick Hillegas wrote:
> Oh bother, said Pooh.. We'd like to write assertion-based tests. What
> do folks think we should do:
>
> o Ask JUnit to license itself under the Apache license.
>
> o Use some other assertion-based test framework. Any suggestions?
>
> -Rick
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: subversion etiquette
> From:
> "Jean T. Anderson" <jt...@bristowhill.com>
> Date:
> Wed, 14 Sep 2005 09:31:48 -0700
> To:
> Derby Development <de...@db.apache.org>
>
> To:
> Derby Development <de...@db.apache.org>
>
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>> Sometime soon I hope to checkin some JUnit-based tests for testing the
>>> compatibility of our clients and servers. As part of this submission, I
>>> want to checkin the JUnit jar itself (into tools/java alongside the
>>> other jars). Is it ok for the svn diff to contain a big binary file
>>> like
>>> this? Will this annoy/confuse reviewers? Is there a more polite way to
>>> submit jar files?
>>
>>
>>
>> I'm not sure you can check Junit's jar into Apache's subversion
>> repository due to its licence (CPL 0.5).
>>
>> http://junit.sourceforge.net/doc/faq/faq.htm#overview_7
>
>
> Dan is correct; we cannot check CPL-licensed software/files into Apache.
>
> For example, we couldn't check DITA Open Toolkit files into the derby
> svn repository because it is under CPL. We discussed the issue with
> the DITA OT developers and they additionally released it under the ASL
> 2 at the end of August.
>
> Discussions about various licenses pop up on this list:
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ .
>
> -jean
>
Re: JUnit license, was: subversion etiquette]
Posted by John Embretsen <Jo...@Sun.COM>.
Andrew McIntyre wrote:
> Well, there is TestNG:
>
> http://testng.org/doc/
> https://testng.dev.java.net/
>
[snip]
>
> The downside is that it doesn't support JDK 1.3, and I'm guessing it
> doesn't support J2ME either (but then neither does Junit).
Can you explain why JUnit does not support J2ME?
Derby itself supports J2ME CDC (Connected Device Configuration), but not
CLDC (Connected Limited Device Configuration). As far as I know, both
Derby and JUnit uses Java reflection, which is supported on CDC, but not
on CLDC. Thus, the fact that reflection is used by the JUnit framework
should not be an issue. Do you know of any other issues with JUnit on
J2ME CDC?
--
John H. Embretsen
Sun Microsystems,
Database Technology Group, Norway
Re: JUnit license, was: subversion etiquette]
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Andrew,
Thanks for the pointer. For the record, JUnit should be supported on
J2ME/CDC. The small platform problems crop up with CLDC, which we don't
worry about.
Cheers,
-Rick
Andrew McIntyre wrote:
>On 9/14/05, Rick Hillegas <Ri...@sun.com> wrote:
>
>
>>Oh bother, said Pooh.. We'd like to write assertion-based tests. What do
>>folks think we should do:
>>
>>o Ask JUnit to license itself under the Apache license.
>>
>>o Use some other assertion-based test framework. Any suggestions?
>>
>>
>
>Well, there is TestNG:
>
>http://testng.org/doc/
>https://testng.dev.java.net/
>
>It's licensed under the Apache License, is hosted at java.net, and is
>a part of the OpenSymphony project. It's also got some nifty features,
>like demarcating test methods using javadoc comments or JDK 1.5
>annotations, and it runs Junit tests 'out-of-the-box' (or so it says,
>I haven't tried it). It's also geared towards supporting different
>kinds of testing and is not strictly targeted at unit testing.
>
>The downside is that it doesn't support JDK 1.3, and I'm guessing it
>doesn't support J2ME either (but then neither does Junit). It might
>not be the choice for the short term, but maybe we should give it some
>consideration for the long term, since I believe there's agreement
>that 10.3 will no longer support JDK 1.3.
>
>andrew
>
>
Re: JUnit license, was: subversion etiquette]
Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/14/05, Rick Hillegas <Ri...@sun.com> wrote:
> Oh bother, said Pooh.. We'd like to write assertion-based tests. What do
> folks think we should do:
>
> o Ask JUnit to license itself under the Apache license.
>
> o Use some other assertion-based test framework. Any suggestions?
Well, there is TestNG:
http://testng.org/doc/
https://testng.dev.java.net/
It's licensed under the Apache License, is hosted at java.net, and is
a part of the OpenSymphony project. It's also got some nifty features,
like demarcating test methods using javadoc comments or JDK 1.5
annotations, and it runs Junit tests 'out-of-the-box' (or so it says,
I haven't tried it). It's also geared towards supporting different
kinds of testing and is not strictly targeted at unit testing.
The downside is that it doesn't support JDK 1.3, and I'm guessing it
doesn't support J2ME either (but then neither does Junit). It might
not be the choice for the short term, but maybe we should give it some
consideration for the long term, since I believe there's agreement
that 10.3 will no longer support JDK 1.3.
andrew