Community
Participate
Working Groups
There is currently an issue in the Mockito bundle in Orbit that might be worth addressing with an update. Both, Mockito and JUnit depend on Hamcrest. However, the latest JUnit bundle uses a Require-Bundle dependency on org.hamcrest.core;bundle-version="1.3.0". In contrast, Mockito using a package import (org.hamcrest;version="[1.0,2.0)") which is usually fine but conflicts with the JUnit/Hamcrest Orbit setup. The reason is that the "org.hamcrest.core" bundle exports the package with split-package attributes. Only the "org.hamcrest" bundle exports the packages without such attributes. However, the org.hamcrest bundle is version 1.1 and only the org.hamcrest.core bundle has been updated to 1.3. This causes some nasty exceptions when running tests such as: java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher; Looks like this: http://stackoverflow.com/questions/7869711/getting-nosuchmethoderror-org-hamcrest-matcher-describemismatch-when-running Long story short, I'd recommend following the JUnit bundling and specifying a Require-Bundle dependency. If someone gets the Mockito bundle from Orbit they are likely consuming the other bundles from Orbit too. The other option is to reach out to the JUnit bundle maintainers. But then again, the missing Hamcrest bundles need to be updated first.
So it looks like the root seems to be an incompatibility between the 1.3 core version (introduced by bug 400130) and the 1.1 other artifacts.
Note that Hamcrest's AnyOf suffers from a breaking API change. In 1.1, it had: public static <T> Matcher<T> anyOf(Matcher<? extends T>... matchers) In 1.3, it has: public static <T> AnyOf<T> anyOf(Matcher<? super T>... matchers) I'm not sure this particular problem is due to a mix between Hamcrest 1.1 and 1.3 classes (would need to see the complete stacktrace to judge this). This change in Hamcrest breaks binary compatibility for all callers of that method. Orbit's take on this is usually that this is the clients' problem. If Mockito needs the complete Hamcrest 1.3, then please file an IP request ASAP. Maybe it just needs to be recompiled to work with Hamcrest 1.3. See also http://code.google.com/p/mockito/issues/detail?id=423
So, who owns solving this .. for M7 and Kepler? Sounds to me that restricting Mockito's prereq range to [1.0,1.3) is a perfectly valid solution to make here? In this case?
Could we (please) switch to package dependency? This would leave it open for the users to switch to own packages where needed. The bundle dependencies are IMHO to strict. I faced the described problem in my current project and had to switch out all orbit bundles with our own. The strongest issue was the same as in bug369717. This is why I started to (strongly) encourage my clients to use package dependency in case of bundle dependency when it comes to 3rdParty libraries. Another problem is the split-package in the hamcrest bundles. With the switch to package dependency it wouldn't be such a problem anymore because folks could bundle hamcrest-all in their products. If there are no objections I would opt-in to solve this for the current junit/hamcrest/mockito packages in orbit. Please tell me, if there are possible problems in going this way?
Ok, just found out that the whole hamcrest-split-package story is due to the bug360659. So I'm even more positive that we can just concentrate on switching to package dependency on this bug.
I'm not in principle against using Import-Package. But before touching the org.junit and org.hamcrest.core bundles in Orbit, we need a patch with the proposed changes, so that this can be tested thoroughly. org.junit 4.11 currently contains: Require-Bundle: org.hamcrest.core;bundle-version="1.3.0";visibility:=r eexport I tried to replace this with: Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=cor e,org.hamcrest.core;version="1.3.0"; or: Import-Package: org.hamcrest;version="1.3.0";core=split,org.hamcrest .core;version="1.3.0"; ... but it didn't work. org.junit and dependent bundles were not loaded any more). I can't speak for the org.hamcrest bundle and Mockito (the Eclipse SDK doesn't use those).
(In reply to comment #6) > I'm not in principle against using Import-Package. But before touching the > org.junit and org.hamcrest.core bundles in Orbit, we need a patch with the > proposed changes, so that this can be tested thoroughly. > > org.junit 4.11 currently contains: > Require-Bundle: org.hamcrest.core;bundle-version="1.3.0";visibility:=r > eexport > > I tried to replace this with: > Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=cor > e,org.hamcrest.core;version="1.3.0"; Should not use the mandatory directive on the importing side. It should be ignored at runtime, but it is not needed. > > or: > Import-Package: org.hamcrest;version="1.3.0";core=split,org.hamcrest > .core;version="1.3.0"; Note that using Import-Package effectively will remove the 'reexport' of org.hamcrest.core from the org.junit bundle. Most know my negative views on re-export, but usually this is viewed as a breaking API change. > > ... but it didn't work. org.junit and dependent bundles were not loaded any > more). What does not loaded mean here? I assume that means it is no longer resolved? Do you have the error? > > > I can't speak for the org.hamcrest bundle and Mockito (the Eclipse SDK > doesn't use those).
Created attachment 229832 [details] Log I hacked a clean I20130416-0800 install by removing plugins\org.junit_4.11.0.v201303080030\META-INF\ECLIPSE_.*" and applying said changes to the MANIFEST.MF. Also removed the signatures at the end and made sure the file still ended with two empty lines. The log just tells me that everything that depends on org.junit is not resolved -- but I don't know why.
(In reply to comment #7) > > I tried to replace this with: > > Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=cor > > e,org.hamcrest.core;version="1.3.0"; > > Should not use the mandatory directive on the importing side. It should be > ignored at runtime, but it is not needed. Tom, my observations in the past do not confirm this. I always had issues with PDE and Equinox when trying to use import-package with split packages so I ended up using require-bundle. That were other bundles/packages (eg. Lucene), though.
Another workaround is to add a dummy bundle which depends on all the Hamcrest bundles and re-exports their packages without split-package header.
(In reply to comment #10) > Another workaround is to add a dummy bundle which depends on all the Hamcrest > bundles and re-exports their packages without split-package header. Would it be ok to create this new bundle which would bind hamcrest and hamcrest.core and distribute it with the EPPs?
(In reply to comment #6) > I tried to replace this with: > Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=cor > e,org.hamcrest.core;version="1.3.0"; I think there is a ';' to much at the end. I tried your test. Download M6-classic and just changing the manifest in org.junit: - removing the require-bundle lines - adding the Import-Package lines: Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=core, org.hamcrest.core;version="1.3.0" And eclipse started without issue. What we have to consider is the reexport which will be removed. Would it sufficient to communicate this on the cross-project-list?
Created attachment 229864 [details] Screenshot of running eclipse 4.3M6 with junit having package dependency to hamcrest.core
> I think there is a ';' to much at the end. Thanks, that's it! Filed bug 406006 for better diagnostics. > What we have to consider is the reexport which will be removed. Would it > sufficient to communicate this on the cross-project-list? No, this is a breaking API change and needs PMC approval. Especially since we're past the API freeze. Impact on OSGi-based users of org.junit: - projects that use Hamcrest classes must add Hamcrest as an explicit dependency - projects that don't use Hamcrest classes can still be launched with a JUnit Plug-in Test launch configuration. But plain JUnit launch configurations won't work any more, since the PDE classpath container doesn't contain Hamcrest any more: java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing. Impact on users of JDT's "JUnit Library" classpath container: - none (still contains both bundles) Note that the JUnit project has also changed their mind about this: In 4.4., they shipped just one junit.jar that also contained org.hamcrest classes. Later releases added a junit-dep.jar that didn't contain Hamcrest. Nowadays (4.11), they only ship JUnit and refer to Hamcrest as a dependency. => I wouldn't switch to Import-Package lightly, but if we have positive feedback from Mockito users that this will solve their problems, then we can consider it.
(In reply to comment #12) > Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=core, > org.hamcrest.core;version="1.3.0" > > And eclipse started without issue. > I still argue that the directive ;mandatory:=core is not needed and should just have this: Import-Package: org.hamcrest;version="1.3.0";core=split, org.hamcrest.core;version="1.3.0" (In reply to comment #14) > > What we have to consider is the reexport which will be removed. Would it > > sufficient to communicate this on the cross-project-list? > > No, this is a breaking API change and needs PMC approval. Especially since > we're past the API freeze. > I agree with Markus's assessment on the impact. It seems pretty high to me. One hack to reduce the pain could be to use an optional requirement but even that is really playing games with the framework: Require-Bundle: org.hamcrest.core;bundle-version="1.3.0";visibility:=reexport;resolution:=optional The imported packages will always be used since imported packages terminate the search and do not allow the OSGi class loader to continue delegation to the required bundles, but if the org.hamcrest.core bundle is present then it would allow it to be re-exported to bundles that require junit.
(In reply to comment #15) > (In reply to comment #12) > > Import-Package: org.hamcrest;version="1.3.0";core=split;mandatory:=core, > > org.hamcrest.core;version="1.3.0" > > > > And eclipse started without issue. > > > > I still argue that the directive ;mandatory:=core is not needed and should > just have this: > > Import-Package: org.hamcrest;version="1.3.0";core=split, > org.hamcrest.core;version="1.3.0" > > (In reply to comment #14) > > > What we have to consider is the reexport which will be removed. Would it > > > sufficient to communicate this on the cross-project-list? > > > > No, this is a breaking API change and needs PMC approval. Especially since > > we're past the API freeze. > > > > I agree with Markus's assessment on the impact. It seems pretty high to me. > One hack to reduce the pain could be to use an optional requirement but even > that is really playing games with the framework: Same here. I'm -1 for this change at this point, but will discuss it with the other PMC members next week.
(In reply to comment #16) > (In reply to comment #15) > > I agree with Markus's assessment on the impact. It seems pretty high to me. > > One hack to reduce the pain could be to use an optional requirement but even > > that is really playing games with the framework: > > Same here. I'm -1 for this change at this point, but will discuss it with > the other PMC members next week. +1 for the change with the addition from Thomas: Optional Bundle Dependency.
(In reply to comment #16) > Same here. I'm -1 for this change at this point, but will discuss it with the > other PMC members next week. Did you discuss this issue? If yes, what was the outcome? Thanks and greetings Stephan
(In reply to comment #18) > (In reply to comment #16) > > Same here. I'm -1 for this change at this point, but will discuss it with the > > other PMC members next week. > Did you discuss this issue? If yes, what was the outcome? > > Thanks and greetings > Stephan Sorry, my fault. This felt off the discussion list. Will discuss on May 1.
Note that we won't even consider touching org.junit or org.hamcrest.core for Kepler unless we have a proposed patch and a confirmation that the proposed solution actually works for users of Mockito and Hamcrest. In the SDK, we don't use Mockito. This work needs to be done by somebody who is interested in Mockito. The only thing the PMC can reasonably decide at this point is whether there's a chance that anything might be touched or not. IMHO, the PMC has better things to do than that.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #16) > > > Same here. I'm -1 for this change at this point, but will discuss it with the > > > other PMC members next week. > > Did you discuss this issue? If yes, what was the outcome? > > > > Thanks and greetings > > Stephan > > Sorry, my fault. This felt off the discussion list. Will discuss on May 1. The PMC unanimously decided that making such a breaking change is a no go - at least for Kepler. We might reconsider for Luna, if there is really no other solution. But so far, we not even got any feedback on the proposed solution (see also comment 20).
FYI, a similar errors happens in SWTBot tests when simply replacing hamcrest 1.1 by hamcrest 1.3 in target platform. Some pieces of code did need a fix to compile, but during test execution, the same error java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher; appears at execution. Longer stack: java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher; at org.hamcrest.number.OrderingComparisons.greaterThanOrEqualTo(OrderingComparisons.java:20) at org.hamcrest.number.OrderingComparisons.lessThan(OrderingComparisons.java:27) at org.eclipse.swtbot.swt.finder.waits.WaitForShellTest.waitsForShellToAppear(WaitForShellTest.java:52) In this case, there is no hamcrest 1.1 bundle in the environment. All Hamcrest bundles (core, library, integration) are available in environment -I can see them in eclipse.ini- and are in version 1.3. It's using hamcrest 1.3 from Orbit, recently added as part of bug #405276 Short version: even with a full migration to hamcrest 1.3, this issue remains, and seems to be internal to hamcrest (OrderingComparisons comes from org.hamcrest.library 1.3; anyOf is found in org.hamcrest.core 1.3). Any hint would be welcome (follow bug 404346 ).
Seems early enough in Luna we should give some of the proposed solutions a try. I'll try "owning" this now ... but, will re-read more carefully before settling on what to try.
May I ask what the status of this bug is? Is it possible to try it on Integration? The Eclipse Scout project is interested in a solution to consume Mockito 1.9.5 from Orbit. This would be a more better solution than having our own mockito bundle in our repository. We want to help, what can we do?
(In reply to Jeremie Bresson from comment #24) > May I ask what the status of this bug is? > > Is it possible to try it on Integration? > > The Eclipse Scout project is interested in a solution to consume Mockito > 1.9.5 from Orbit. This would be a more better solution than having our own > mockito bundle in our repository. > > We want to help, what can we do? I don't see Mockito 1.9.5 in Orbit ... was that a typo? Or you mean that you will put 1.9.5 in Orbit once problem solved for Mockito 1.8.4?
(In reply to David Williams from comment #25) > I don't see Mockito 1.9.5 in Orbit ... was that a typo? Or you mean that you > will put 1.9.5 in Orbit once problem solved for Mockito 1.8.4? That is exactly so: bringing Mockito 1.9.5 in Orbit is my end goal. This should be realized with Bug 403635, but this bug (bug 403676) is a kind of blocker to move forward (see your comment 11 in Bug 403635 [1]). The IP Process is already OK. We just need to move forward in Orbit, this is why I asked here how the scout project can help. The other possibility for us is to have our Mockito bundle in the Scout project (CQ is also good for that), but for a main stream library like Mockito this is a disappointing solution. I am pretty confident that bringing the latest version of Mockito in Orbit, in a way that is compatible with CBI, will be a benefit for all the eclipse projects. * * * In my opinion, now is good time to switch with Luna to package dependency for junit/hamcrest/mockito * * * [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=403635#c11
(In reply to Jeremie Bresson from comment #24) > Is it possible to try it on Integration? What is "it"? As long as nobody offers a successfully tested solution, nothing will be changed in Orbit. Releasing something to Orbit is only the last step after all the integration has already been done locally. > We want to help, what can we do? Check if Mockito 1.9.5 also works with Hamcrest 1.3 (see comment 2 and the bug referenced there). If it doesn't work, then help the Mockito team to update their dependencies and make it work. JUnit 4.11 needs org.hamcrest.core 1.3, and we don't intend to hack anything to make it work with older versions. The assessment from comment 14 still holds. Orbit generally doesn't modify the original sources, so if you need a custom version of Mockito to make it work with Hamcrest 1.3, then Orbit is probably not the place for that. If Mockito just needs the rest of Hamcrest updated to 1.3, then prepare Orbit projects for that, and once everything works locally, then - open a bug to include the rest of Hamcrest 1.3 in Orbit and - reopen bug 403635
Can we use the following Mockito version or it is still somehow corrupted? http://download.eclipse.org/tools/orbit/downloads/drops/I20140114130914/repository/plugins/org.mockito_1.9.5.v201311280930.jar Daniel
(In reply to Daniel Rolka from comment #28) > Can we use the following Mockito version or it is still somehow corrupted? > > http://download.eclipse.org/tools/orbit/downloads/drops/I20140114130914/ > repository/plugins/org.mockito_1.9.5.v201311280930.jar > > Daniel Unfortunately it is still "somehow" corrupted.
I'm not sure who the right "owner" for this should be ... but just realized how it might be confusing that I was listed as "assignee". So please feel free to "take over" the bug and drive to resolution.
(In reply to David Williams from comment #30) > I'm not sure who the right "owner" for this should be ... but just realized > how it might be confusing that I was listed as "assignee". > > So please feel free to "take over" the bug and drive to resolution.
(In reply to David Williams from comment #30) > I'm not sure who the right "owner" for this should be ... but just realized > how it might be confusing that I was listed as "assignee". > > So please feel free to "take over" the bug and drive to resolution. Oh, but, meant to emphasize, if there is something I can help with, please let me know.
FWIW, the latest SWTBot requires (as in Require-Bundle) org.hamcrest.core in version 1.3.0, which effectively prevents one from using Mockito in SWTBot-driven tests.
Hi, is there any update on the issue? I just tried to use Mockito from Orbit for plugin-tests and came across this issue and the explanation on stackoverflow. Somewhere in the comments it says it is a client issue and should be solved there. Is there any hint on how to solve the issue locally? I don't have a clue on how it should be possible to get Mockito working in JUnit 4 testing of Eclipse plugins by using the Orbit version. Any help is appreciated. Greez, Dirk
BTW - in Orbit the Mockito bundle is named "Mockito Mock Library for Java. Hamcrest-core & Objenesis included in the bundle" But it doesn't look like hamcrest and objenesis is included in the bundle. I can only find org.mockito. Or does it mean hamcrest and objenesis are downloaded as additional bundles, because I can find them in the plugins?
Well, I've been struggling trying to get this to work without success as well. Everytime I startup a bundle that has a dependency it doesn't start due to mockito not finding the package it expects. Unresolved requirement: Import-Package: org.hamcrest; version="[1.0.0,2.0.0)" I've tried adding org.hamcrest.core as a required plugin and also via the import package method described earlier. Neither works. If I manually use the mockito-all.jar that works as expected.
I just ran into the very same issue. Any hints how to solve this?
(In reply to Lars Schuetze from comment #37) > I just ran into the very same issue. Any hints how to solve this? I'm sorry to say this, but we solved it by using our own bundled plugins deployed on our company-site-repository. The plugins hosted on orbit didn't work in any way for us - and I can't imagine they do for anybody.
This will hopefully be solved with the upcoming Mockito 2.0. AFAIK they worked on the hamcrest dependency there.
I looked and in case others are curious, I can save you the trouble, JUnit 4.12 still has require bundle hamcrest version 1.3 visibility=reexport. I believe others have implied the fix is required on the Mockito side? Did anyone ever open a bug there?
(In reply to David Williams from comment #40) > I looked and in case others are curious, I can save you the trouble, JUnit > 4.12 still has > > require bundle hamcrest version 1.3 visibility=reexport. > > I believe others have implied the fix is required on the Mockito side? > > Did anyone ever open a bug there? Yes, someone did: https://code.google.com/p/mockito/issues/detail?id=397&q=hamcrest
I think this is fixed, as we have a newer version of Mockito in Orbit.
