Bug 292052 - Custom start up and startlevel configuration for product bundles
Summary: Custom start up and startlevel configuration for product bundles
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Buckminster (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: buckminster.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-12 11:02 EDT by Alex Chatziparaskewas CLA
Modified: 2019-02-25 14:39 EST (History)
2 users (show)

See Also:


Attachments
Sample project (217.51 KB, application/x-zip)
2009-10-12 11:03 EDT, Alex Chatziparaskewas CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Chatziparaskewas CLA 2009-10-12 11:02:56 EDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Eclipse: I20090611-1540, Buckminster: r10546 (highest revision I found)

When it comes to the definition of bundles start levels and startup behaviour, the default config ini generated is usually insufficient (for more complex projects). So it needs some tweaking, which seems possible through the eclipse product definition.

The sample project contains a feature based product definition (/test.product/test.product.product), which in its configuration defines a specific start up and start level for the bundle 'org.eclipse.equinox.common'. By default the PDE sets the start level of this bundle to 2.

The test case: The test product definition - /test.product/test.product.product - defines the start level of 'org.eclipse.equinox.common' to be 5.

Now, do the following:

1) Please refer to the embedded readme project/file.
2) Invoke the buckminster action 'site.p2' on the 'test.updatesite' project using the 'buckminster properties' as defined in /test.updatesite/buckminster.properties'.
3) Open the 'Ant' view.
4) Add the ant script /deployer/test-install.xml to the 'Ant' view.
5) Execute the target: unzip-platform
	Unzips an eclipse platform
6) Execute the target: install-buckminster
	uses the p2 directory for installing the 'some.ID' product from the previously created update site.

Under D:/temp/test/dcvl (default), you find the installed product. 
Looking into configuration/config.ini reveals that configured start level for org.eclipse.equinox.common is 2 instead of the expected 5.

The test project allows to do the same using the PDE as a reference:
1) Export the /test.product/test.product.product as 'Plug-in Development/Eclipse product'.
	a) Use 'eclipse' as root directory
	b) Set the destination to directory, e.g. D:\temp\test
	c) !!! Unselect 'Synchronize before exporting' (otherwise the product definition is screwed - at least in my installation)
	d) Tick generate metadata repository
	e) Select Finish
=> This creates two additional directories 'eclipse' and 'repository' under the defined rootdir ( e.g. D:\temp\test ).
2) Rename or remove any existing 'dcvl' directory under D:\temp\test
3) Execute the Ant target: install-eclipse (same installation procedure as above, but different repository)

Here the correct start level is set  for org.eclipse.equinox.common.

Reproducible: Always
Comment 1 Alex Chatziparaskewas CLA 2009-10-12 11:03:55 EDT
Created attachment 149370 [details]
Sample project
Comment 2 Thomas Hallgren CLA 2009-10-12 12:10:11 EDT
Does this apply to the org.eclipse.equinox.common bundle specifically or to other bundles as well? The reason I ask is that PDE maintains a list of default start levels for some bundles. Something is wrong regardless of course. An explicitly defined start level should have higher precedence.
Comment 3 Alex Chatziparaskewas CLA 2009-10-12 13:07:40 EDT
The example only refers to those bundles for which some default is set. One of our current product has a bigger problem, where only one of maybe 20 plugins has a start level assigned. All others have no start level whatsoever anymore. However, I have not been able constructing an example reproducing this problem so far.
Comment 4 Stefan Reger CLA 2009-12-14 15:02:29 EST
I have the same problem here, product config is: 

   <configurations>
      <plugin id="org.eclipse.core.runtime" autoStart="true" startLevel="6" />
      <plugin id="org.eclipse.equinox.cm" autoStart="true" startLevel="1" />
      <plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" />
      <plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="1" />
      <plugin id="org.eclipse.equinox.simpleconfigurator" autoStart="true" startLevel="1" />
      <plugin id="org.eclipse.update.configurator" autoStart="true" startLevel="3" />
      <plugin id="org.ops4j.pax.configmanager" autoStart="true" startLevel="4" />
      <plugin id="org.ops4j.pax.logging.api" autoStart="true" startLevel="5" />
      <plugin id="org.ops4j.pax.logging.service" autoStart="true" startLevel="5" />
   </configurations>


config.ini after site.p2 and director install of product is:
osgi.bundles=reference\:file\:org.eclipse.equinox.cm_1.0.100.v20090520-1800.jar@1\:start,reference\:file\:org.eclipse.equinox.ds_1.1.1.R35x_v20090806.jar@1\:start,reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.101.R35x_v20090807-1100.jar@1\:start


Latest Eclipse 3.5.1 and Buckminster - Core	1.1.350.r10643 used.