Community
Participate
Working Groups
PDE UI is adding support for specifying bundle configuration data in the product file (start levels, auto-start, etc) (bug 240737). ProductAction in the publisher should pick up this data during publication from product files. This will allow PDE build to get rid of its ugly code that currently reverse-engineers this data from hard-coded config.ini/bundles.info files.
I'll take a stab at this.
In addition, if start level information is not provided, we should generate reasonable defaults. In pde.build this is done in ProductGenerator.createConfigIni, and is based on the presence of org.eclipse.equinox.common to determine start levels for equinox.common and core.runtime (due to runtime refactoring in 3.2 compared to 3.1). Also, the configurator is started (update at level 3, simple at 1)
Created attachment 118315 [details] Initial fix This patch adds support for loading config data from product files. I added a few new publisher tests for it, and did a bit of refactoring of the publisher actions at the same time.
I'm not convinced about adding "reasonable defaults". To me the big value of adding this data to the product files is that it allowed us to no longer hard-code these values in the builder logic (we can now fiddle with start levels and auto-start settings in the future without needing changes in the builder or p2).
Most users will not be changing their start levels. If the publisher is given a .product file with no start level information, we still need to set something. This is roughly the case now where pde/build will generate a default config.ini from the .product file, and the metadata generation reads it. It would be nice to skip this step and go straight from .product to metadata. Note that we also have the existing case where the .product file specifies a custom config.ini to use, the publisher will need to be able to consume this to get the correct metadata. I believe the generator code that does this has morphed into the publisher AccumulateConfigData advice
I'm marking this fixed, and opened bug 256019 to consider the best approach for adding default start levels, etc. Re comment #5, I believe ProductFileAdvice already handles loading config data from a config.ini file. In my change I merged this advice with the advice from the p2.inf file, assuming no overlap. It's not clear to me if the config.ini is redundant now that the product file contains config data - I hope so.
(In reply to comment #6) > Re comment #5, I believe ProductFileAdvice already handles loading config data > from a config.ini file. In my change I merged this advice with the advice from > the p2.inf file, assuming no overlap. It's not clear to me if the config.ini is > redundant now that the product file contains config data - I hope so. > See bug 252426, the use case would be that the custom config.ini referenced by the .product file would be a template that is merged with the start level data. Usefull if you wanted some other random properties set in the config.
