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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
