[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Product publishing for all platforms

Given the pain you mentioned, improving the publisher sounds like a good idea.
I also wonder if this will require changes to the product file to ease authoring.
Please file a bug report and we can continue the discussion there.

On 2011-06-05, at 1:29 PM, Yousouf, Shenol wrote:

Hi all,
 
As you know, Eclipse .product files contain a "<configurations>" section where you can specify which bundles you wish to be started by default and at which start level. When such products are published, a special configuration unit for every such bundle is generated in the repository, with touchpoint instructions to fulfill these requirements. The catch is that they are generated with filters for the environment (determined by the "-configs" parameter of product publisher application in a headless build, e.g. "-configs gtk.linux.x86"). Accordingly, the instructions for start will not be executed during p2 install if the filters do not match the corresponding properties of the p2 profile into which you install.
 
Assuming that my product has no platform-specific requirements, how can I publish it so that the start configuration is valid anywhere I install the product ?
 
I guess that this could be achieved if the configuration units were getting published without filters; so far, however, I haven't found a straightforward solution to do it. It is possible to invoke the publisher with "-configs all" option, which, supposedly, implies "configuration for all platforms". However, even in this case the CUs get a minimal filter "osgi.ws=all" which again has to be explicitly matched by the p2 profile. Publishing without specifying "-configs" does not generate any CUs at all.
 
The following article (http://wiki.eclipse.org/Equinox/p2/Setting_Start_Levels) explains how to generate CUs without filters, using p2.inf file. The workaround, however, is not pretty at all - you need to add about 20 lines in p2.inf for the configuration of each bundle; for translating the configuration of a whole product, the final p2.inf would most often look monstrous J (depending on how many bundles you want to customize).
 
Is there a more elegant way to achieve this ? If not, what are your views to seek a more direct solution implemented in the publisher code rather than relying on p2.inf capabilites ?
 
Best regards,
Shenol Yousouf
SAP Labs Bulgaria
 
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev