|Re: [p2-dev] Product publishing for all platforms|
The solution we chose for publishing of configuration units without environment-specific filters, which makes them applicable for all platforms, is to call the publisher applications with “-configs ANY” option (or any case-insensitive variant of “-configs ANY”, “-configs ANY.ANY”, “-configs ANY.ANY.ANY”; e.g. “-configs any” should also be fine). The single effect of the patch implementation is not to assign any filters when the configuration units are being generated in this particular case; it does not alter the publishing process flow in any other way, e.g. the decisions when the configuration units have to be created, etc.
The patch was proposed and approved just a few hours ago (wow, that was fast ! 10x, Pascal ! J). It will benefit mostly those users who maintain and distribute products supporting most or all platforms and feel restricted by the requirement to publish them with a specific set of environment properties. Now, the startup configuration of products, published with “-configs ANY”, will be applied on any operating system and architecture on which the products are being installed.
Since the solution will be visible only for those whole love digging into the p2 publisher code J and is not obvious otherwise, I find it necessary to make it known to all users of p2 publisher applications, the announcement in the p2 mailing list being the first step. Next, I can assist by updating the few Eclipse wiki pages I found on the topic:
- How these pages can be updated ? Any special requirements and permissions ?
- Are there other places which need the same update ?
SAP Labs Bulgaria
Many thanks for your sympathies ! J
I opened a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=348428 on this case, with a few basic suggestions what solutions we could offer to the users of product publisher.
Anybody in the mailing list is welcome to share his/her proposals in the bug.
SAP Labs Bulgaria
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:
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 ?
SAP Labs Bulgaria