The next revision of JUnit, JUnit 4.0 has been released in February 2006. Is there a reason why no new ebuild is available? Or does this got to do with the Java 1.5/5.0 switch?
It might have to do with the switch. If I am not mistaken I think the new junit uses annotations which is new in 1.5. So they are probably not worrying about the new junit until the Java 1.5 is stable on gentoo.
Yeah, I thought about that. I've been using an experimental overlay for java and so far it is excellent. It seamlessly switches between 1.4 and 1.5 depending on the task (emerge something java for example). On my system everything except compilation uses 1.5. I think i'll write an ebuild and submit it at some point. Junit 4.0 is very cool and I'd like to have it in the correct location on my filesystem :)
Since it does need Java 1.5, we'd need to wait for the new java build system to make it into the tree. I expect this to happen in the next week or so. I did look into packging this a little, but regrettfully upstream doesn't seem to release any means of building (ie ant, maven, etc). Not a show stopper, but it is inconvienent.
Created attachment 91234 [details] junit-4.1.ebuild Still todo: - figure how the jar in ant-lib could should be named - some way to switch between junit3 and junit4 in ant is required, otherwise junit4 utilising test cases cannot be run through ant. * This would propably mean that whenever a build target is java >=1.5 the ant script should put junit4.jar into classpath and otherwise use the older junit.jar * other option is to have junit4.jar and junit3.jar and with an external helper script linke either of them to junit.jar and thus force all ant runs to use the wanted version
Created attachment 91243 [details] junit-3.8.2.ebuild I created also junit 3.8.2 ebuild and decided to abuse the bug to slip it in too. Also, looking at the /usr/bin/ant script it would seem that adding symlink to /usr/share/ant-core/lib/junit.jar might no longer be needed, but I'll keep it till someone checks it for sure.
Comment on attachment 91243 [details] junit-3.8.2.ebuild Please file a separate bug for this. One bug, one issue / ebuild / request.
your ebuild is in the overlay thx for your help ant symlink issue still remains open. current ebuild just pack junit jar and slot it SLOT="4" according to javadoc, junit4 uses a completely different api from junit3.8. anyway the same classes are still available in junit4 jar file. will need to figure out if that means junit4 is reverse compatible and therefore if slotting can be avoided https://overlays.gentoo.org/proj/java/browser/migrated-java-experimental-overlay/dev-java/junit
sun-jdk-1.5.* is stable on x86 now, and ~arch on amd64 (-* on all else). It'd be nice to have at least an ~arch version of junit-4.1 in Portage.
The problem is that if we let junit4 in the same slot, everything that uses junit would instantly need to use 1.5 jdk during compilation... and I can imagine there will be packages that can't yet use 1.5 for some API reasons etc. If we slot it (like we do in the overlay), we can use it only for stuff that really needs it. With split-ant-1.7, the problem of selecting the version ant will use is solved. What remains is the problem with old dependencies... all those >=3.8.1 dependencies would now pick 4.x and then the "java-pkg_get-jars junit" would fails if junit-3.8.x is not installed for some other reason. So this means there are lots of deps to update to pull junit-3 specifically. Lots of work that would make more sense if we could use slot deps, but we can't yet. And I even assume we would leave junit3 as SLOT=0 because otherwise it would be even much more work to udpate. But maybe we don't need to specify junit-3* in DEPEND directly. Because such ebuilds already need full dev-java/ant to use <junit> task, which pulls junit-3 itself. So if we didn't convert the deps, ebuilds would pull junit-4 unnecessarily, but the ant dep would ensure there's junit-3 to use.
Updated link to overlay https://overlays.gentoo.org/proj/java/browser/java-overlay/dev-java/junit Also, now that slotted deps are in portage (at least I'm pretty sure they are), can we get this looked at again as it's needed for eclipse 3.3
(In reply to comment #10) > > Also, now that slotted deps are in portage (at least I'm pretty sure they are), > can we get this looked at again as it's needed for eclipse 3.3 > Portage implements them already yes but they can't be used without a new EAPI specification.
There is circular dependency of junit. dev-java/aspectwerkz --> >=dev-java/junitperf-1.9.1 --> dev-java/ant-junit --> dev-java/junit dev-java/jaxme --> dev-java/junit
The full listing: Calculating dependencies... done! [ebuild N ] dev-java/hamcrest-1.1 USE="-doc -source -test" [ebuild N ] dev-java/jmock-1.1.0-r2 USE="-doc -examples -source -test" [ebuild N ] dev-java/cglib-2.0.2-r2 USE="-doc -source" [ebuild N ] dev-java/aspectwerkz-2.0 USE="java5 -doc -source" [ebuild N ] dev-java/dom4j-1.6.1-r2 USE="-doc -source" [ebuild N ] dev-java/jsr173-1.0-r1 USE="-doc -source" [ebuild N ] dev-java/junitperf-1.9.1-r1 USE="-doc -source -test" [nomerge ] dev-java/jsr173-1.0-r1 USE="-doc -source" [ebuild N ] dev-java/jaxme-0.3.1-r4 USE="-doc -source" [ebuild N ] dev-java/junit-4.4 USE="-doc -examples -source -test" !!! Error: circular dependencies: ('ebuild', '/', 'dev-java/hamcrest-1.1', 'merge') depends on ('ebuild', '/', 'dev-java/jmock-1.1.0-r2', 'merge') (hard) ('ebuild', '/', 'dev-java/aspectwerkz-2.0', 'merge') depends on ('ebuild', '/', 'dev-java/junitperf-1.9.1-r1', 'merge') (hard) ('ebuild', '/', 'dev-java/dom4j-1.6.1-r2', 'merge') (hard) ('ebuild', '/', 'dev-java/jsr173-1.0-r1', 'merge') depends on ('ebuild', '/', 'dev-java/jaxme-0.3.1-r4', 'merge') (hard) ('ebuild', '/', 'dev-java/cglib-2.0.2-r2', 'merge') depends on ('ebuild', '/', 'dev-java/aspectwerkz-2.0', 'merge') (hard) ('ebuild', '/', 'dev-java/junitperf-1.9.1-r1', 'merge') depends on ('ebuild', '/', 'dev-java/junit-4.4', 'merge') (hard) ('ebuild', '/', 'dev-java/junit-4.4', 'merge') depends on ('ebuild', '/', 'dev-java/hamcrest-1.1', 'merge') (hard) ('ebuild', '/', 'dev-java/jaxme-0.3.1-r4', 'merge') depends on ('ebuild', '/', 'dev-java/junit-4.4', 'merge') (hard) ('ebuild', '/', 'dev-java/jmock-1.1.0-r2', 'merge') depends on ('ebuild', '/', 'dev-java/cglib-2.0.2-r2', 'merge') (hard) ('ebuild', '/', 'dev-java/dom4j-1.6.1-r2', 'merge') depends on ('ebuild', '/', 'dev-java/jsr173-1.0-r1', 'merge') (hard) ('ebuild', '/', 'dev-java/jaxme-0.3.1-r4', 'merge') (hard)
Ok, seems fixed by restricting deps in jaxme and junitperf to junit-3.8* The problem with FEATURES=test remains though: Calculating dependencies... done! [nomerge ] dev-java/junit-4.4 USE="test -doc -examples -source" [ebuild N ] dev-java/hamcrest-1.1 USE="test -doc -source" [ebuild N ] dev-java/easymock-2.3 USE="test -doc -examples -source" [ebuild N ] dev-java/junit-4.4 USE="test -doc -examples -source" !!! Error: circular dependencies: ('ebuild', '/', 'dev-java/hamcrest-1.1', 'merge') depends on ('ebuild', '/', 'dev-java/easymock-2.3', 'merge') (hard) ('ebuild', '/', 'dev-java/junit-4.4', 'merge') depends on ('ebuild', '/', 'dev-java/hamcrest-1.1', 'merge') (hard) ('ebuild', '/', 'dev-java/easymock-2.3', 'merge') depends on ('ebuild', '/', 'dev-java/junit-4.4', 'merge') (hard) I suppose we could workaround this by removing the dep in easymock, and do a has_version instead which will skip tests and give ewarn if junit4 is not installed yet.
OMG it's in the tree! Took less than two years! Needs rekeywording for deps though: dev-java/qdox-1.6.3 (only some arches) dev-java/hamcrest-core-1.1 dev-java/junit-4.4 dev-java/ant-junit4-1.7.0
make it dev-java/junit-4.4-r1, bumped it because -r0 was in java-overlay and people might have it installed, but the hamcrest dependency changed.
ppc64 done with deps
keyworded ~x86
~ia64 done
~ppc added
done, finally
