Bugzilla – Full Text Bug Listing
| Summary: | Add the org.eclipse.pde.junit.runtime.* features to the ep build | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Hugues Malphettes <hmalphettes> | ||||||
| Component: | Releng | Assignee: | Kim Moir <kim.moir> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aniefer, daniel_megert, jeffmcaffer, kim.moir, mknauer | ||||||
| Version: | 3.6 | ||||||||
| Target Milestone: | 3.7 M2 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Hugues Malphettes
I agree that having these features be properly maintained and built for the release is awesome. Many people we encounter doing OSGi development love this setup. Not sure where this goes, I assume you are talking about some EPP package In fact they would be part of the eclipse platform repository. These features are used by OSGi developers who create their own Target Platform from scratch and populate it with RT features. http://wiki.eclipse.org/Jetty/Tutorial/Jetty-OSGi_SDK#Configure_a_Target_Platform_and_run_a_simple_Test_Unit_with_PDE We have not identified an EPP package that would need this feature. Let me know if this makes sense. Moving to platform releng So are you asking us to (1) reconsume these features from a jetty repository or (2) rebuild the features and bundles from source. I assume (1)? Created attachment 177358 [details] Archive of the features projects from jetty's svn Hi Kim, (2) is what we would like. We would like to not publish them anymore from the jetty repository. They include only a set of bundles that are published in the platform repository; No jetty related artifacts. Please find attached the archive of those features as committed currently in jetty's svn: http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/trunk/jetty-features/org.eclipse.pde.junit.runtime.standalone/ http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/trunk/jetty-features/org.eclipse.pde.junit.runtime.addon/ and here is how we contribute them to helios: <features name="org.eclipse.pde.junit.runtime.standalone.feature.group" versionRange="1.0.0.v20100816"> <categories href="helios.b3aggr#//@customCategories[identifier='EclipseRT%20Target%20Platform%20Components']"/> </features> <features name="org.eclipse.pde.junit.runtime.addon.feature.group" versionRange="1.0.0.v20100816"> <categories href="helios.b3aggr#//@customCategories[identifier='EclipseRT%20Target%20Platform%20Components']"/> </features> (I don't have a strong opinion on the version. The ids were reviewed by the pde guys and Jeff in bug 313202) Thanks! Seems like what we need to do is add the two features to the Eclipse project CVS and to the platform build. One tweak is that we don't really want the eclipse.org bundles recompiled. We just want the features "built" and published with the normal build output. Not sure how this is done in the build today. Ultimately the features should also be contributed as roots to the Indigo build and categorized as Target Components. So you are asking us to create these features in the Eclipse project's CVS repository org.eclipse.pde.junit4.runtime.standalone org.eclipse.pde.junit4.runtime.addon Since the bundles they include already exist in our build, we will just include these two features in our master feature that we use to assemble all build components. This will result in two new features being included in our repository which can then be included in the Indigo build. Is this correct? (In reply to comment #8) > Since the bundles they include already exist in our build, we will just include > these two features in our master feature that we use to assemble all build > components. This will result in two new features being included in our > repository which can then be included in the Indigo build. Is this correct? Yes that is perfect. Thanks a lot! The PDE folks should agree on the name etc (believe they did previously) but yeah, that's what we are after. Created attachment 177727 [details]
patches
Note bug 324198 points out a problem in one of the features. This should be addressed in the new copy of the feature. Verified in test build. Released for N20100902-2000 and tagged for i-build. The features reside here org.eclipse.sdk-feature/features/org.eclipse.pde.junit.runtime.addon org.eclipse.sdk-feature/features/org.eclipse.pde.junit.runtime.standalone Super. I do have one further suggestion though. The version number of these features should be set to 1.0.1.qualifier. Reasons - The addons feature actually did have a bug fix since its 1.0.0 release - The build mechanism used for the new features is different and we would otherwise have to confirm that the computed qualifier will in fact be monotonically greater than the original. feature versions have been incremented and tagged for i-build >Super. I do have one further suggestion though. The version number of these
>features should be set to 1.0.1.qualifier. Reasons
Shouldn't it be 1.0.100 then since we use the .1 for service releases?
indeed you are right. Kim, can you tweak the features? I've incremented the feature versions. I am able to build the web-starterkit for indigo pointing at the new junit features. Two questions: 1- Is the platform site going to provide source features too? 2- Currently I can see the new features in the nightly build: eclipse/updates/3.7-N-builds/N20101023-2000 But I can't see them in the I-builds. In general I do not support creating source features for every runtime feature we create. IMHO the overhead is too great. I'd rather see the PDE workflows etc be smoother for getting source. (In reply to comment #20) > In general I do not support creating source features for every runtime feature > we create. IMHO the overhead is too great. I'd rather see the PDE workflows > etc be smoother for getting source. OK thanks for the info Jeff. I was not sure whether this was temporary or not. I agree with you. I have forked p2director to install the sources bundles it can find that match the bundles it is installing. That solution works really well for us and we don't prepare source features anymore for our internal projects. I'll try to prepare a patch that makes this approach available in PDE. I forgot to tag this for the I-build. It has been tagged for the next build. (In reply to comment #21) > I have forked p2director to install the sources bundles it can find that match > the bundles it is installing. That solution works really well for us and we > don't prepare source features anymore for our internal projects. > I'll try to prepare a patch that makes this approach available in PDE. Interesting. a patch there would be good. I have been preparing changes to PDE UI target management that would allow for a "I'd like source with that" checky box. So along the same lines, we would not have to worry too much about creating source features. See Bug 328929. |