Bugzilla – Full Text Bug Listing
| Summary: | Support for PDE's JUnit Runner in jetty's target platform | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Hugues Malphettes <hmalphettes> | ||||||||||
| Component: | osgi | Assignee: | Hugues Malphettes <hmalphettes> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | darin.eclipse, david_williams, d_a_carver, jeffmcaffer, jetty-inbox, john.arthorne, markus.kell.r, tjwatson | ||||||||||
| Version: | 7.1.0 | ||||||||||||
| Target Milestone: | 7.1.0 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 168774 [details]
Simple "Test as plugin" executed in the corresponding target platform
This feature is contributed via the jetty build to the Helios repository starting with RC1. As discussed in the mailing list: Starting with helios RC2 the id of the feature is "org.eclipse.pde.junit4.runtime" and the version "3.6.0.qualifier". The PDE project will take ownership of this feature for the next release. The current feature has a nice characteristic that it is standalone. However, if you already have a product or launch configuration that identifies particular versions of OSGi, runtime, ... then those versions may conflict with the ones defined here. The answer is to make a "addon" feature that simply "includes" the 4 testing related bundles and "requires" org.eclipse.core.runtime (the others will be transitively included). This feature can then be added to an existing configuration without conflict. The downside here is that the "requires" are not necessarily followed when setting up the target platform (depends on a UI switch). So we have two competing goals/use-cases. A solution would be to provide features that satisfy both cases. I'll attach a proposed structure here. Basically there are the following features org.eclipse.pde.junit.runtime.standalone = the feature as defined originally org.eclipse.pde.junit.runtime.addon = *includes* the 4 testing bundles and *requires* o.e.c.runtime org.eclipse.pde.junit.runtime.target = added to the target platform category in the Helios repo and used for target population. It *includes* the other two features. This satisfies the target provisioning case as well as the two runtime scenarios. Note that I talked to the PDE folks and they are good with using the PDE namespace and would refer "runtime" in the name rather than "runner" as it fits better with their lexicon. OK I am working on that. Jeff, I used to be unable to install any feature contributed by the jetty build unless the checkbox "Include required dependencies" was unchecked: https://bugs.eclipse.org/bugs/show_bug.cgi?id=313454. This is why I was very focused on providing standalone features. I have put in place a workaround in the jetty build so we don't have this problem anymore. I am following your advice unless you think that we can make do with the "addon" model alone. Thanks, Hugeus Created attachment 169708 [details]
standalone feature
This is the standalone feature. I added the sources of junit as this feature is only useful for developers using PDE.
Created attachment 169709 [details]
addon feature
The addon feature. Also with the junit sources.
I tested that I can install this addon feature with the checkbox "Add Required Dependencies"
Contributed to Helios starting with RC2. First successful aggregator build that contains these features is #57 (May 24, 2010 1:15:51 PM) looking good. Some suggestions. - the feature version numbers should be 1.0.0.qualifier - Suggest that standalone and addon NOT point to the junit source. there should be a "Junit Bundle Testing Target Components" or some such feature that can include source and the standalone and addon features. - suggest confirming the feature names with the PDE folks to see if they want "junit" or "junit4" - I assume that the commented out part of the addon feature will just be removed? (In reply to comment #9) > - suggest confirming the feature names with the PDE folks to see if they want > "junit" or "junit4" In the past "org.junit4" was used as the symbolic name for the org.junit bundle version 4.x, because there was an issue with the automated test infrastructure (in terms of which Junit it would choose to run tests, I think). However, that has been resolved in Helios, and now multiple versions of the junit bundle are now included in the SDK simply as "org.junit" (v 3.x and v 4.x). In keeping with the model of one name and multiple versions, it would be consistent to use "junit" with a descriptive version identifier. However, I'm not sure how/if this should be extended to features. CC'ing John and Markus for comment. (In reply to comment #9) > looking good. Some suggestions. > > - the feature version numbers should be 1.0.0.qualifier OK done. > > - Suggest that standalone and addon NOT point to the junit source. there > should be a "Junit Bundle Testing Target Components" or some such feature that > can include source and the standalone and addon features. I think that in this case it is useful to always bundle the sources for JUnit: this feature is only meant for OSGi developers who use PDE; I can't see a scenario where one would provision a runtime with these bundles. The JUnit tests are developed against the JUnit API and so these are the sources that are useful to those users. The sources of the jdt and pde integration remain hidden. I don't mind preparing another feature and it would be more consistent with a typical "RT Target Platform" packaging. If we decide to make such a feature: should "JUnit Bundle Testing Target Components" include 'addon' or 'standalone' ? Unless I am mistaken that is an exclusive choice. I would also suggest naming it "PDE JUnit Bundle Testing Target Components" to make it clear what it depends on. > > - suggest confirming the feature names with the PDE folks to see if they want > "junit" or "junit4" Ok, thanks for pointing that out: re-reading your previous comment, it is clear it is "junit" not "junit4". (In Reply to comment #10) Waiting for further comments from John and Markus. Will rename it as "junit" otherwise as hinted by Darin. > > - I assume that the commented out part of the addon feature will just be > removed? Done. (In reply to comment #11) > I think that in this case it is useful to always bundle the sources for > JUnit: this feature is only meant for OSGi developers who use PDE; I can't see > a scenario where one would provision a runtime with these bundles. > The JUnit tests are developed against the JUnit API and so these are the > sources that are useful to those users. The sources of the jdt and pde > integration remain hidden. You add these features to the runtime when you want to run the tests :-) Interestingly, I had the opposite reaction. "Why would I want the source in my test harness?" Yes, I need the source for developing but not for running. > I don't mind preparing another feature and it would be more consistent with a > typical "RT Target Platform" packaging. We need the other feature regardless. That is, the Target Platform category in the repo should not have two testing options. Users should just see "stuff you need for testing" and then they can sort out how they want to configure things once they have the testing support. > If we decide to make such a feature: should "JUnit Bundle Testing Target > Components" include 'addon' or 'standalone' ? Unless I am mistaken that is an > exclusive choice. Both. Remember, these are just features that are being added to help users configure their runtime/test-time environment. One might have 5 or 10 or ... different configurations of your function that make sense. You could include all of those "runtime" features in the Target Components feature. They get delivered to the development environment (target) and the user configures a launch/product/... to use whatever they need. > I would also suggest naming it "PDE JUnit Bundle Testing > Target Components" to make it clear what it depends on. Sure. (In reply to comment #12) OK Doing just what you described. Makes perfect sense. (In reply to comment #10) > In keeping with the model of one name and multiple versions, it would be > consistent to use "junit" with a descriptive version identifier. However, I'm > not sure how/if this should be extended to features. > > CC'ing John and Markus for comment. +1, "JUnit" sounds good to me. The symbolic name "org.junit4" was really a hack and the version number generally shouldn't appear in the name. In Helios, we still use 'junit4' in places where a plug-in provides special support for JUnit 4. JUnit is a bit special, since JUnit 4 is effectively a new framework that just happens to be somewhat compatible with JUnit 3, but it's not really an evolution of the original JUnit. The "hack" with junit4 in the name avoids a lot of problems in PDE that are still present in Helios, that's why we e.g. still have 'org.eclipse.jdt.junit4.runtime'. We just made two versions of org.junit because that made it easier to adapt the Eclipse Test Framework. Looking at the patch in comment 7, I'm not sure why this worked for you. I would have expected that you need to include plug-in org.eclipse.jdt.junit4.runtime as well, since that implements the communication between the JUnit view and JUnit4 in the runtime (and the screenshot from comment 1, it looks like the JUnit 4 Runner was correctly used). I have documented the usage of his feature here: http://wiki.eclipse.org/Jetty/Tutorial/Jetty-OSGi_SDK#Configure_a_Target_Platform_and_run_a_simple_Test_Unit_with_PDE It is really not related to Jetty so let me know if you want to have it else where in the wiki. (In reply to comment #15) > Looking at the patch in comment 7, I'm not sure why this worked for you. I > would have expected that you need to include plug-in > org.eclipse.jdt.junit4.runtime as well, since that implements the communication > between the JUnit view and JUnit4 in the runtime (and the screenshot from > comment 1, it looks like the JUnit 4 Runner was correctly used). Thanks for reviewing it. I don't know the internals of the JUnit Runner for PDE. I made the wiki page yesterday and verified that it works fine as it is currently. I had to change the contribution to Helios though so it is not yet on staging. Contributing directly the standalone and add-on features. |
Created attachment 168773 [details] standalone pde.junit for rt target platform feature Currently there is no feature to provision a new target platform where it is possible to create new JUnit tests and run them with PDE. Attached is a standalone feature to do that. It includes the minimum equinox, junit (v4.8.1), jdt.junit.runtime and pde.junit.runtime bundles to run a testunit. I can publish it as part of the jetty's p2 repository that is placed in helios.