Community
Participate
Working Groups
Is/was there a reason for this? I know it was being built in 3.8 but for some reason it was commented out in org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/build.xml I recall there being issues "fixing" the 4.2 repo (for Juno aggregation) specifically for this ... but, not sure why it was commented out? I'll try a run or two with it uncommented, and see what blows up :)
Ok, now I see what blows up :) Off hand it looks like its simply not being built (and hence, not in the local build repo when it goes to package it). I assume the project/feature is in git; perhaps just a matter of getting it tagged or in repositories.txt file? I'll dig deeper, but will just comment it out again, for now. = = = = pde-api: [delete] Deleting directory /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/featureTemp [mkdir] Created dir: /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/featureTemp BUILD FAILED /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/buildAll.xml:67: The following error occurred while executing this line: /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/buildAll.xml:808: The following error occurred while executing this line: /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/build.xml:6: The following error occurred while executing this line: /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/build.xml:22: The following error occurred while executing this line: /shared/eclipse/eclipse4/build/supportDir/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/repos/build.xml:90: Unable to find: Installable Unit [ id=org.eclipse.pde.api.tools.ee.fragments.feature.group version= ] Total time: 63 minutes 16 seconds
adding Curtis to CC. Curtis, any of this sound familiar? Any history? I assume there is a real feature somewhere that "builds" these? org.eclipse.pde.api.tools.ee.fragments? Where is that?
David, the feature name was changed in master see bug 353844. Not sure if this was fixed in the 4.x stream.
Looking at the repositories it looks like two copies of the feature exist. One in PDE UI, which is the 'real' version. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/tree/apitools/org.eclipse.pde.api.tools.ee.feature And one in Platform releng. http://git.eclipse.org/c/platform/eclipse.platform.releng.git/tree/features/org.eclipse.pde.api.tools.ee.fragments?h=master In Bug 353844 we cleaned up the EE fragment structure (handled by a p2.inf in the feature). Kim ran a test 3.x build and cleaned the old fragments from the generated p2 repository. We would want the description fragment built and included in 4.x repositories, but they aren't included in the SDK.
Ok, so, suspect the main fix is to change the eclipsebuilder to use "the real" feature: <target name="pde-api"> <buildRepos feature="org.eclipse.pde.api.tools.ee.feature" /> </target> instead of previous <target name="pde-api"> <buildRepos feature="org.eclipse.pde.api.tools.ee.fragments" /> </target> Let me know if I've misunderstood.
also found a spot in testManifest.xml that had "fragments" instead of "feature", so assuming that needs to be fixed too ... even though I don't know what testManifest.xml is yet :) org.eclipse.pde.api.tools.ee.fragments <zipType name="PDE Runtime"> <platform id="PRR" name="<img src = "repo.gif"> PDE Repo " fileName="org.eclipse.pde-@build@.zip"></platform> <platform id="PAR" name="<img src = "repo.gif"> PDE API Tools execution environment fragments repo" fileName="org.eclipse.pde.api.tools.ee.feature-@build@.zip"></platform> </zipType>
Thanks Kim and Curtis. Your hints made it easy to fix. http://build.eclipse.org/eclipse/eclipse4/build/supportDir/I20120403-1714/org.eclipse.pde.api.tools.ee.feature-I20120403-1714.zip Surprisingly enough, the link on 3.8 downloads page was/is broken (bug 376028) now seems to have been fixed automagically ... I bet that's what the "testManifest.xml" file controlled. We are getting close now! :)
