Community
Participate
Working Groups
When creating a product with buckminster as outlined in the MailApp example, the finished product is missing org.eclipse.rcp_root. Subsequent attempts to install org.eclipse.rcp (directly or transitively through dependencies) fail due to the missing requirement. Steps to reproduce: 1. Materialize http://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster/trunk/org.eclipse.buckminster.tutorial.mailapp.releng/developer.mspec 2. Perform org.eclipse.buckminster.tutorial.mailapp.releng#create.product 3. Notice that the resulting MailApp product does not contain MailApp/notice.html or other files contributed by rcp_root 4. Try installing org.eclipse.rcp.feature.group into it: director -repository http://download.eclipse.org/eclipse/updates/3.5 -destination /path/to/MailApp -bundlepool /path/to/MailApp -profile MailProfile -profileProperties org.eclipse.update.install.features=true -installIU org.eclipse.rcp.feature.group Result: Installing org.eclipse.rcp.feature.group 3.5.2.R35x_v20100119-9SA0FxwFnoCU5XxWItFdXXb27BA6. Installation failed. Cannot complete the install because one or more required items could not be found. Software currently installed: Mailapp test build 1.0.0 (org.eclipse.buckminster.tutorial.mailapp.product 1.0.0) Missing requirement: Eclipse RCP 3.5.2.R35x_v20100119-9SA0FxwFnoCU5XxWItFdXXb27BA6 (org.eclipse.rcp.feature.group 3.5.2.R35x_v20100119-9SA0FxwFnoCU5XxWItFdXXb27BA6) requires 'org.eclipse.rcp_root [3.5.2.R35x_v20100119-9SA0FxwFnoCU5XxWItFdXXb27BA6]' but it could not be found Cannot satisfy dependency: From: Mailapp test build 1.0.0 (org.eclipse.buckminster.tutorial.mailapp.product 1.0.0) To: org.eclipse.buckminster.tutorial.mailapp.product.feature.feature.group [1.0.0] Cannot satisfy dependency: From: Mailapp Product Feature 1.0.0 (org.eclipse.buckminster.tutorial.mailapp.product.feature.feature.group 1.0.0) To: org.eclipse.rcp.feature.group [3.5.2.R35x_v20100119-9SA0FxwFnoCU5XxWItFdXXb27BA6] Uninstalling and reinstalling org.eclipse.rcp.feature.group works correctly. cf. http://www.eclipse.org/forums/index.php?t=msg&th=172745
Investigating further, as Thomas said, the error on installing org.eclipse.rcp does not happen with the 3.5 director. However, even with the 3.5 director the files from org.eclipse.rcp_root are not added to the product, neither on product creation nor on subsequent installation of org.eclipse.rcp. Again, after un- and reinstalling, they are there.
The problem goes beyond the director. The 3.6 director is correct actually and reveals a deeper problem that occurs during publishing. In essence, the PDE target platform and p2 publisher combination is incapable of republishing a feature that contains root files. As far as I can tell, both PDE build and Buckminster suffers from this. Here is what happens: 1. The org.eclipse.rcp feature is created from source and published to a p2 repository. When this happens, the p2 publisher will create a zip file that contains the root files for the feature. It will also create an associated IU, the org.eclipse.rcp_root, that represents this zip artifact. 2. The org.eclipse.rcp feature is provisioned into the target platform. The target platform however, doesn't really do a proper install of the feature and doesn't include the binary part. In addition, the meta-data (the actual IU) for the feature is lost since the TP doesn't maintain a meta-data repository. 3. An attempt is made to publish the org.eclipse.rcp feature (i.e. site.p2 action). Buckminster finds the feature in the TP, creates a jar, and recreates the IU based on the feature.xml. The feature does however no longer contain the build.properties and the root files. Hence, the new IU will differ from the original and the binary artifacts are now missing. This is a bad situation and I'm not sure how to tackle it. I see three alternatives: Alternative 1. Detect republishing and issue a warning When an attempt is made to publish a feature for which there is no source, Buckminster could issue a warning to inform the user that the root binaries might be missing. Alternative 2. Improve the TP provisioning. We make sure that the feature as a whole ends up in the TP so that it's IU and binary can be accessed during publishing. The drawback of this approach is that it will not work unless you use Buckminster to provision the TP. Using the importtargetdefinition command will not work until PDE changes how the TP handles features. Another possible drawback is that the introduced resolution of the binary artifact is likely to break many builds that uses RMAP's with 'eclipse.feature,osgi.bundle' as the only possible component types for p2 repositories. Alternative 3. Introduce repositories to pick from during publishing. If Buckminster is made aware of repositories where it can find things during publishing, it could use what it finds there rather then using the TP. In essence, this means that Buckminster would make TP provisioning a two step process. Step 1 would simply mirror the metadata + artifact for the found IU's into a local repository. Step 2 would create a TP from this repository. The publisher would then use the repository rather then the TP. This is not a trivial effort but it might be worth it. It would be done in combination with alternative #1.
Created attachment 175457 [details] Changes to create.product Here's what I changed in the create.product action to circumvent the issue
[Oops, wrong posting order...] Ouch, that appears to be not so good. Alternative 3 sure sounds charming though ;) Lucky for me, after your explanation the problem seems easily circumvented as far as the product build is concerned. I just changed the repository list used in the director call in create.product to have the eclipse platform repository as first element. Director now picks up org.eclipse.rcp from there instead of the target platform, correctly installs org.eclipse.rcp_root and everything runs smoothly. The drawback is of course that the build is no longer self-contained but needs external repository access and that it won't work that easily if the external repository contains artifacts we also build from source ourselves, which in my case is not an issue.
hmm i just ran into this bug when moving my builds to an hpux machine. I have an root packed jre that i deliver with my product, when i started there was an bug that hindered the check box "include jre" in the product file to work, and as an workaround i delivered the jre as an feature instead, but now when moving this to hpux just as you descibe below happend. Rest of the product builds but i don't get my root packed jre with me. any work around for this? as i use site.p2 action to build my product.
