Community
Participate
Working Groups
It appears that JUnit 4.9 is getting close to release. When it is added to orbit, would it be possible to get the build without hamcrest? Having hamcrest included in the junit bundle is problematic. For example, the latest version of JMock needs hamcrest 1.3. Including the hamcrest 1.3 bundle with the junit 4.8 bundle causes very bad things to happen.
The org.junit bundles from Orbit never included Hamcrest, and I don't see a reason why this would be changed now. According to http://tech.groups.yahoo.com/group/junit/message/23576 , JUnit 4.9 has been released and can be fetched from here: https://github.com/KentBeck/junit/downloads
Ah, my bad, I had just assumed that the junit bundle included the hamcrest library. It seems the problems I've encountered may stem from: Require-Bundle: org.hamcrest.core;bundle-version="1.1.0";visibility:=reexport I think the reexport is what is causing my problems, so I think I need to change my request to remove the reexport when putting junit 2.9 into Orbit.
I have JUnit 10 built as a bundle / feature. Should I attach it for contribution?
Bryan, sorry if I'm stating the obvious, but the a third party bundle needs to go through the Eclipse Foundation's IP Process first (i.e. a committer on an Eclipse Project file a CQ files, etc.). (Plus, a new addition would be best as a separate bugzilla entry, as I think this one is about a possible bug in an existing one?) I'll assign this to DJ, as he maintains the JUnit family of bundles so he can decide course of action. Thanks,
The latest JUnit version is 4.10: http://tech.groups.yahoo.com/group/junit/message/23717 (In reply to comment #2) > Ah, my bad, I had just assumed that the junit bundle included the hamcrest > library. It seems the problems I've encountered may stem from: > > Require-Bundle: org.hamcrest.core;bundle-version="1.1.0";visibility:=reexport > > I think the reexport is what is causing my problems, so I think I need to > change my request to remove the reexport when putting junit 2.9 into Orbit. We can't remove the reexport, since that would be a breaking change. If the reexport is really the problem, then you have to come up with a proof for that and discuss the concrete problem with the OSGi people.
> We can't remove the reexport, since that would be a breaking change. If the > reexport is really the problem, then you have to come up with a proof for that > and discuss the concrete problem with the OSGi people. I think I remember how to reproduce the problem. I'll see if I can come up with a test case that I can attach.
JDT's CQ for JUnit 4.10 is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5958
Created attachment 214453 [details] org.junit_v4.10.zip DJ, the IPZilla has been approved. Could you please release the new version to Orbit?
Ok, I've added Bug 377553 to track release into Orbit. Here is the Orbit CQ I just opened to piggy-back off the JDT one: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6442
Created attachment 214598 [details] Fixes for v4_10_0 branch This patch fixes problems in the v4_10_0 branch in the Orbit CVS: - project name should contain version - classpath problems: missed PDE container, missed EE, didn't export junit.jar > Ok, I've added Bug 377553 to track release into Orbit. Not sure what that bug is for. This bug is already for Orbit. Bug 356065 is the JDT/UI bug (blocked by this bug).
*** Bug 377553 has been marked as a duplicate of this bug. ***
Oops, for some reason I thought this was the JDT bug. I've closed the other as a duplicate. Thanks, I released the patch. The latest build page doesn't seem to contain last night's build with the changes. I've added the bug as a blocker.
Build is available here: http://build.eclipse.org/orbit/committers/ Please take a look at the bundle available from the build. I won't close this bug until the bundle is verified. Thanks.
Thanks, I verified that - http://build.eclipse.org/orbit/committers/orbit-I/20120427112720/I20120427112720/repository/plugins/org.junit_4.10.0.v4_10_0_v20120426-0900.jar and the source bundle are looking good - they also work fine when I hack them into an install
Closing.
