You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Bill Barker <wb...@wilshire.com> on 2006/02/18 04:33:15 UTC
[VOTE] Resolving JUnit failures
<Ja...@rzf.fin-nrw.de> wrote in message
news:B07F6610DABEA8438092ED2058D7F1668A1F02@z011134.bk.fin.local...
http://vmgump.apache.org/gump/public/junit/junit/gump_work/build_junit_junit.html
>CLASSPATH :/opt/jdk1.4/lib/tools.jar ...
> [javac] Compiling 139 source files to /x1/gump/public/workspace/junit
> [javac]
> /x1/gump/public/workspace/junit/junit/extensions/ActiveTestSuite.java:20:
> ><identifier> expected
> [javac] public ActiveTestSuite(Class<? extends TestCase> theClass) {
>
>
>It seems that JUnit needs Java5, but got only a 1.4...
Yup. It seems like our options are:
1) Change vmgump to run with Java 5, and hope that the ~50% coverage we got
last time has been fixed by their respective projects (it's been awhile, so
who knows :).
2) Change the 196 projects that <depend /> on JUnit to used packaged-junit
(ugh).
3) Change JUnit to build from a branch (not as bad as 2, but still not what
Gump is about)
4) Just hope that the JUnit project comes to their senses, and restores JVM
1.4 compatibility (not likely, given how extensive the change seems to be).
If it wasn't for the fact that most projects that adopt Java 5 also seem to
soon after move to exclusively requiring Maven2, I'd vote 1) (e.g. mina).
If JUnit plans to do that as well, we might as well do 2) or 3), since Gump
support for Maven2 seems a long way off :(.
And, actually, the inclusion of the [VOTE] is more in the hopes of getting
people to actually read this. So, if anybody has any better ideas to
resolve this, just add them to the list, and they will be counted. Also,
since this is mostly metadata, I'm considering all votes from ASF committers
binding (although, as always, the Gump PMC could choose to override this :).
And, needless to be said, I'm volunteering for any grunt-work that needs to
be done to implement it (please vote 1 or 4 :).
>Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [VOTE] Resolving JUnit failures
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 17 Feb 2006, Bill Barker <wb...@wilshire.com> wrote:
> Yup. It seems like our options are:
>
> 1) Change vmgump to run with Java 5, and hope that the ~50% coverage
> we got last time has been fixed by their respective projects (it's
> been awhile, so who knows :).
+1 and that's what I intended to do for a while now, just need to find
tht time to do it.
> 2) Change the 196 projects that <depend /> on JUnit to used
> packaged-junit (ugh).
>
> 3) Change JUnit to build from a branch (not as bad as 2, but still
> not what Gump is about)
There will never be a release from that branch, so we can as well
package up JUnit 3.8.1. If (1) doesn't work (because of other
backwards incompatibilities in JUnit that may be there) we can
selectivly use that.
> 4) Just hope that the JUnit project comes to their senses, and
> restores JVM 1.4 compatibility (not likely, given how extensive the
> change seems to be).
They won't. This is a conscious decision to break JDK 1.4 support and
in many places they do so for good reasons.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: [VOTE] Resolving JUnit failures
Posted by Steve <mc...@apache.org>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Bill Barker
> Sent: Saturday, 18 February 2006 2:03 PM
> To: general@gump.apache.org
> Subject: [VOTE] Resolving JUnit failures
>
>
> <Ja...@rzf.fin-nrw.de> wrote in message
> news:B07F6610DABEA8438092ED2058D7F1668A1F02@z011134.bk.fin.local...
> http://vmgump.apache.org/gump/public/junit/junit/gump_work/bui
> ld_junit_junit.html
> >CLASSPATH :/opt/jdk1.4/lib/tools.jar ...
> > [javac] Compiling 139 source files to
> /x1/gump/public/workspace/junit
> > [javac]
> >
> /x1/gump/public/workspace/junit/junit/extensions/ActiveTestSui
> te.java:20:
> > ><identifier> expected
> > [javac] public ActiveTestSuite(Class<? extends TestCase>
> theClass)
> >{
> >
> >
> >It seems that JUnit needs Java5, but got only a 1.4...
>
> Yup. It seems like our options are:
> 1) Change vmgump to run with Java 5, and hope that the ~50%
> coverage we got last time has been fixed by their respective
> projects (it's been awhile, so who knows :).
> 2) Change the 196 projects that <depend /> on JUnit to used
> packaged-junit (ugh).
+1
> 3) Change JUnit to build from a branch (not as bad as 2, but
> still not what Gump is about)
> 4) Just hope that the JUnit project comes to their senses,
> and restores JVM
> 1.4 compatibility (not likely, given how extensive the change
> seems to be).
-1
Gump (and the projects it supports) needs to recognize that we have two
distinct products (the 3.X line and the 4.X line). After all - the 4.X line
is bringing a bunch of improvements to testing that would not be
realistically achievable without JDK5.
/Steve.
> If it wasn't for the fact that most projects that adopt Java
> 5 also seem to soon after move to exclusively requiring
> Maven2, I'd vote 1) (e.g. mina).
> If JUnit plans to do that as well, we might as well do 2) or
> 3), since Gump support for Maven2 seems a long way off :(.
>
> And, actually, the inclusion of the [VOTE] is more in the
> hopes of getting people to actually read this. So, if
> anybody has any better ideas to resolve this, just add them
> to the list, and they will be counted. Also, since this is
> mostly metadata, I'm considering all votes from ASF
> committers binding (although, as always, the Gump PMC could
> choose to override this :).
> And, needless to be said, I'm volunteering for any grunt-work
> that needs to be done to implement it (please vote 1 or 4 :).
>
> >Jan
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org