| product building and p2 materializer strangeness again [message #387943] |
Fri, 17 July 2009 16:09 |
 Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Hi,
After I thought I'd reached the finishing line on my journey towards automated headless product builds with Buckminster, I had a few
setbacks that got me stumped for the last two days.
My product is a bit complicated to build due to several feature patches that need to be included (see
http://www.eclipse.org/newsportal/article.php?id=1178&gr oup=eclipse.tools.buckminster#1178). So I thought the best way to go here was to
create an absolutely minimal RCP feature just containing the application/branding plugin alongside the equinox and efc stuff, build that and
then install the rest of our features and their dependencies into that.
So, starting with my minimal RCP feature. Two choices here regarding eclipse dependencies (equinox, ecf etc.)
1. materialize into workspace as binary bundles
2. materialize into target platform
Choice 1 did not work for me, because in the #site.p2 action triggered during product build, I always got something like
CSpec org.apache.commons.logging:osgi.bundle$1.0.4.v200904062259 has no action, group, or local artifact named bundle.and.fragments
where the actual varied, but always was either a binary plugin in the workspace or something from the target platform.
With choice 2, it seemed to work out, but only with a few tricks. I had to do
rm -rf /path/to/target-platform # start fresh
buckminster setpref targetPlatformPath=/path/to/target-platform
buckminster resolve -D targetPlatformPath=/path/to/target-platform rcp.mspec
buckminster setpref targetPlatformPath=/path/to/somewhere/else
buckminster setpref targetPlatformPath=/path/to/target-platform
Without the last two steps I always got this during #site.p2:
perform 'rcp.feature#site.p2'
Platform install location: /home/creckord/buckminster/buckminster
Target platform provided by class org.eclipse.buckminster.pde.internal.PDETargetPlatform
org.eclipse.equinox.security.ui:osgi.bundle/[1.0.100.v200905 20-1800,1.0.100.v20090520-1800]: Using resolver rmap
org.eclipse.equinox.security.ui:osgi.bundle/[1.0.100.v200905 20-1800,1.0.100.v20090520-1800]: Rejecting provider
eclipse.platform(plugin/${buckminster.component}): No component match was found
Doing full workspace refresh
Waiting for jobs to end
where again the actual bundle sometimes varied (I also saw org.eclipse.equinox.launcher and org.apache.commons.logging). The "missing"
component is actually there, seems to be a refresh problem with the target platform.
After some fiddling I finally got me a base product and the next order of action would be installing the rest of our stuff into it. Just
appoint the base product as target platform and let the p2 materializer do its work. This actually worked quite well. But the outcome was
not quite what I expected. Depending on how I got to my base product, the "Installation Details" dialog showed
1) with the decribed minimal RCP as base product:
- Installed software: Our minimal RCP feature with included Eclipse RCP and Platform, none of our additional features
- Features: org.eclipse.(platform|rcp|help)
- Plug-ins: RCP + everything installed afterwards
- Installation History: Current Installation
Although none of our additional features show up, everything seems to work
2) with Eclipse SDK retrieved by director as base product:
- Installed software: Eclipse SDK, none of our additional features
- Features: just Eclipse SDK features
- Plug-ins: just Eclipse SDK plug-ins, ours don't show up at all...
- Installation History: Several entries that seem to match p2 materializer runs judging from date and time
Obviously, with our plug-ins being completely ignored, we get a vanilla Eclipse SDK
What I would have expected as a result in both cases would have been the equivalent of starting with the base product and installing
everything else from the Update UI, that is our additional features showing up under Installed Software (or at least being recognized as
features at all...). Is there a way to get the materializer behave that way? Or could this result be achieved by some post-processing step
(involving some magic p2 ant task or some such)?
Finally, some unrelated questions:
- I seem to recall once seeing an example that suggested that it was possible to put a cquery into a component's root directory, which would
then automagically be used in the resolution of that component's dependencies. But hard as I try, I can't make that work :( Did I dream this
up or am I doing something wrong?
- I've had a lot of headache with tracking down unexpected provider selection in my rmaps caused by wrong property mangling. Would it be
possible to already show the expanded properties in the debug log when a provider is tried, instead of just when it is used for
materialization (with the p2 materializer we don't get even that)?
- Regarding resolution filters: What's the idea behind applying them after trying the provider? Can the filter expression match attributes
of the resolved artifact's meta-data? Otherwise I'd have expected the provider not to be contacted at all.
- And one that's probably more for the P2 group: When I have org.eclipse.equinox.executable in my RCP feature and do a #site.p2 with
target.os=macosx, I get
java.io.FileNotFoundException: /tmp/p2.brandingIron723/Eclipse.app/Contents/MacOS/eclipse (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.eclipse.equinox.internal.p2.core.helpers.FileUtils.zipFi le(FileUtils.java:357)
at org.eclipse.equinox.internal.p2.core.helpers.FileUtils.zip(F ileUtils.java:286)
at org.eclipse.equinox.internal.p2.core.helpers.FileUtils.zip(F ileUtils.java:251)
at org.eclipse.equinox.p2.publisher.AbstractPublisherAction.pub lishArtifact(AbstractPublisherAction.java:479)
at org.eclipse.equinox.p2.publisher.eclipse.EquinoxExecutableAc tion.publishExecutableIU(EquinoxExecutableAction.java:122)
at org.eclipse.equinox.p2.publisher.eclipse.EquinoxExecutableAc tion.perform(EquinoxExecutableAction.java:65)
at org.eclipse.equinox.p2.publisher.eclipse.ApplicationLauncher Action.perform(ApplicationLauncherAction.java:66)
at org.eclipse.equinox.p2.publisher.eclipse.ProductAction.perfo rm(ProductAction.java:92)
at org.eclipse.buckminster.pde.tasks.ProductAction.perform(Prod uctAction.java:71)
at org.eclipse.equinox.p2.publisher.Publisher.publish(Publisher .java:172)
at org.eclipse.buckminster.pde.tasks.P2SiteGenerator.run(P2Site Generator.java:351)
Phew, that was quite a lot... Not to stress you guys' support too much, when I get things running here, I could probably do a little
write-up on our setup (and the pitfalls and best practices found along the way).
Best regards,
Carsten
|
|
|
Powered by
FUDForum. Page generated in 0.03316 seconds
] 
Search
Help
Register
Login
Home
