Bugzilla – Full Text Bug Listing
| Summary: | JUnit can not find test class if you run with Categories runner | ||
|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | Adomas <adomas.greicius> |
| Component: | bundles | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | adomas.greicius, alf_s, david, david_williams, jan.sievers, markus.kell.r, niklas.deutschmann, saulius.tvarijonas, simon_kaegi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 386964 | ||
|
Description
Adomas
Orbit is meant to hold 3rd party libraries packaged as OSGi bundles in a fairly standard way emulating how the 3rd party library owner might package it. Eclipse-BuddyPolicy is not a standard OSGi header so I think we probably should not add this header. Instead you can provide the visibility you need by creating an OSGi fragment of the JUnit bundle that imports your category class. Category is standard junit 4.8.1 feature. http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html Main problem is in Junit org.junit.runner.Description public Class<?> getTestClass() { String name= getClassName(); if (name == null) return null; try { return Class.forName(name); } catch (ClassNotFoundException e) { return null; } } getTestClass could not load classes from other bundles. I can change my code in many ways, but Junit runner in eclipse do not run tests without this policy. Main problem is that Category runner could not load Junit test class not category class. There is Bundle-BuddyPolicy, but I am not sure if it works. DynamicImport-Package: * would solve this problem Simon, I agree to Adomas on this issue. JUnit library CATEGORY feature depends on it, so it should a standard OSGi header for JUnit. Actually it doesn't matter how we will achieve it, using BuddyPolicy or DynamicImport. The main idea is if you will try use categories feature from JUnit you will fail with current bundle manifest. IMO making a fragment or changing manifest for everyone is not a convenient option. What is the point of such a standard if it blocks some features? Moreover everybody who will want to use this JUnit feature, will need to waste a time on figuring out why it doesn't work in Eclipse. Why not make everybody happy? :) Simon, what problems do you see here if we change BuddyPolicy or DynamicImport? Markus, do you have thoughts on this one? Exists a workaround for this problem now, I would be very happy if a solution would be provided soon. I first also thought we have no other choice than opening up the visibility, but after a closer look, I found that this is a design bug in recent versions of JUnit 4. From the beginning, the framework has been designed carefully to avoid classloader issues: It passes around Class objects and avoids reflection to find classes. org.junit.runner.Description#getTestClass() was a bad idea, since it breaks this design. Please follow up with the JUnit team. This bug should be fixed in JUnit itself (ideally before Categories gets moved out of the "experimental" package). (In reply to comment #7) > I first also thought we have no other choice than opening up the visibility, > but after a closer look, I found that this is a design bug in recent versions > of JUnit 4. > > From the beginning, the framework has been designed carefully to avoid > classloader issues: It passes around Class objects and avoids reflection to > find classes. org.junit.runner.Description#getTestClass() was a bad idea, since > it breaks this design. > > Please follow up with the JUnit team. This bug should be fixed in JUnit itself > (ideally before Categories gets moved out of the "experimental" package). org.junit.runner.Description#getTestClass() was a bad idea for so many reasons. The current version of Categories will not make it out of experimental. I found the following workaround: Make JUnit and your test plugins class-loading buddies (add "Eclipse-BuddyPolicy:registered" to JUnit's MANIFEST.MF in your target platform and "Eclipse-RegisterBuddy: org.junit" to the MANIFEST.MFs of your test plugins) If I'm reading the chain of comments correctly, the fundamental problem was not in our bundle definition, but JUnit code. And we typically don't "fix" (or work around) other code that's being actively developed. I hope its been fixed in more recent versions? If not, maybe consumers should avoid that experimental class? But in any case, will close this bugzilla was as "not eclipse". Please re-open if I've misunderstood. just for reference, here is the junit bug causing the issue https://github.com/junit-team/junit/issues/364 |