Bugzilla – Full Text Bug Listing
| Summary: | The basic package does not contain the p2 meta data bundles.info | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Florian Waibel <fwaibel> |
| Component: | RTP | Assignee: | Project Inbox <rtp.all-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | hmalphettes, holger.staudacher |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Florian Waibel
Hi Florian, Comparing the RTBasic and RTWeb product files, I think that RTBasic would generate the bundles.info if we add one plugin: <configurations> .... <plugin id="org.eclipse.equinox.simpleconfigurator" autoStart="true" startLevel="1" /> Once that line is added the bundles.info is generated. Let me know if you want me to commit this change. Another difference is the start level for org.eclipse.equinox.ds: it is set at level 2 for RTWeb and level 1 for RTBasic. Do you know if there is a best practice? I will change the RTWeb product file so that it is as close as possible to the RTBasic one. There is another difference with the way RTBasic is started and RTWeb is started. The one in RTWeb supports reading arguments in the eclipse.ini file. If we use p2-director to install RTBasic with a bundle-pool instead of a roaming installation, an eclipse.ini file is created that contains the path to the bundle pool. For example: -startup ../bundlepool/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar The RTWeb's start.sh is read this parameter and produces the correct java -jar ../bundlepool/... If we use p2 to install additional features and bundles onto an RTBasic installation, p2 might create an eclipse.ini file where jvm arguments and other parameters are stored. In fact RTWeb's start.sh will merge jvm arguments defined in JAVA_OPTS with the jvm arguments read in eclipse.ini. The start.bat of RTWeb is a little behind its unix version as it does not support the JVA_OPTS merge. It supports everything else. Hi Hugues, thanks for your quick response. It would be great if you push this change to enable bundles.info generation for the RTBasic. In a discussion with Holger we came up with the idea to include the RTBasic feature in the RTWeb product. This approach could eliminate the duplicate simpleconfigurator configuration. What do you think? In my current case study for RTBasic I use the weaving service, which has to be started very early. After questioning other org.eclipse.equinox.ds users I suggest using start level 3 for declarative services. +1 for using a bundle-pool for RTBasic. Would it be possible to use the same start scripts for both RTWeb and RTBasic? Great, that change is pushed. We are debugging why everything built perfectly on my machine a few hours ago and why it does not build now.. Agreed we should definitely have the RTWeb include the RTBasic's feature. There is a bit of limitation to be able to reuse the RTBasic's feature in RTWeb: we need to agree on the launcher: The launcher files are root files associated to the RTBasic's feature. I am biased with he launcher script but I need them for my use. Florian, are you OK using the more complex launcher script? It will support the functionality of the one you are currently using. It supports a lot many ore things really. That's fine to me. Let's use yours for both RT packages. Does this mean that this bug can be closed now? Hugues, did you pushed the changes? Yes, I did push the change for start.sh and for RTWeb's feature: http://git.eclipse.org/c/rtp/org.eclipse.rtp.git/commit/?id=b6fde4e9a50a6464e831df5557799937485ec59d |