Request Rules Governing Whether Artifacts (Plug-ins) Are Unpacked or Unzipped in Target Platform [message #546088] |
Sat, 10 July 2010 21:09 |
David Lynch Messages: 1 Registered: July 2010 |
Junior Member |
|
|
Friends, can someone explain to me or point me to resources that explain the rules that govern whether the P2 installer will unpack (unzip or inflate) plug-ins in the target environment?
At first glance, this would seem to be indirectly controlled by the feature.xml document (I'm assuming the unpack attribute somehow gets transcribed into content.xml).
I have a case where I have two features (i.e., two feature.xml files). There are about 50 plug-ins defined, but only two are flagged to unpack (i.e., the unpack attribute is missing). The features share some plug-ins in common.
I use these features (and their related plug-ins) as inputs to org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher , which creates my artifacts.jar and contents.jar.
However, when use function "Install New Software..." and point the virgin Eclipse (Galileo) platform to a Local Update Site that contains my features, plugins, artifacts.jar and contents.jar (plus my site.xml), the installer seems to unpack all of my plug-ins, irrespective of the unpack attributes in the antecedent feature.xml files.
When I look at the eclipse/plugin directory after the install, there are a bunch of folders (I was hoping to see JARs in there).
I was unable to find a document that defines the format of content.xml, which I'm assuming indirectly controls unpacking. I'm guessing that these elements are relevant:
<instruction key='zipped'>
true
</instruction>
Thanks in advance for your assistance, I'm really stuck here. I even tried to debug the installation process, but that turned out to be a little more complex than I had imagined.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02886 seconds