Tuesday, December 28, 2010

Inside P2's profile (2) - the fragment matches all osgi bundles

Recently our installer met a strange bug, it didn't uninstall all legacy bundles after updating to new version. Finally I found it's due to a magic fragment is missing in the profile due to some causes.

    <unit id='tooling.osgi.bundle.default' version='1.0.0' singleton='false'>
      <hostRequirements size='1'>
        <required namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' range='0.0.0' multiple='true' greedy='false'/>
      </hostRequirements>
      <properties size='1'>
        <property name='org.eclipse.equinox.p2.type.fragment' value='true'/>
      </properties>
      <provides size='2'>
        <provided namespace='org.eclipse.equinox.p2.iu' name='tooling.osgi.bundle.default' version='1.0.0'/>
        <provided namespace='org.eclipse.equinox.p2.flavor' name='tooling' version='1.0.0'/>
      </provides>
      <requires size='1'>
        <required namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' range='0.0.0' multiple='true' greedy='false'/>
      </requires>
      <touchpoint id='null' version='0.0.0'/>
      <touchpointData size='1'>
        <instructions size='4'>
          <instruction key='install'>
            installBundle(bundle:${artifact})
          </instruction>
          <instruction key='uninstall'>
            uninstallBundle(bundle:${artifact})
          </instruction>
          <instruction key='unconfigure'>

          </instruction>
          <instruction key='configure'>
            setStartLevel(startLevel:4);
          </instruction>
        </instructions>
      </touchpointData>
    </unit>

It has 'hostRequirements' element that represents it's a fragment IU and match all the eclipse's plug-ins in that profile. And this fragment defines the touch point actions for its hosts that will do installBundle action during 'install' phrase and uninstallBundle action during 'uninstall' phrase. It's a very good way to remove the duplicate touch point definitions for all eclipse's plug-ins in the profile.

BTW, p2's engine also doesn't attach this fragment to the eclipse's plug-in IU if the top level IU doesn't have the STRICT rule. I'm not sure the root cause of designing for it, but it's the fact.

Inside P2's profile (1) - inclusion rules

You would see some interesting properties at the bottom of eclipse's profile.

For example,
<iuProperties id='org.eclipse.sdk.ide' version='3.6.1.M20100909-0800'>
      <properties size='2'>
        <property name='org.eclipse.equinox.p2.internal.inclusion.rules' value='STRICT'/>
      </properties>
</iuProperties>

It attaches a property named 'org.eclipse.equinox.p2.internal.inclusion.rules' with value 'STRICT' on the IU 'org.eclipse.sdk.ide' with version 3.6.1.M20100909-0800.
 
It's a very important property for the p2 engine. It means the IU 'org.eclipse.sdk.ide' has been explicitly installed into the profile, so it's not allowed be implicitly updated or removed.

For example,
We have top feature IU 'org.eclipse.sdk.ide' that represents the Eclipse SDK,   'org.eclipse.pde.feature' that represents the Plug-in Development Tool and 'org.eclipse.jdt.feature' that represents the Java Development Tool. And both JDT and PDT are part of Eclipse SDK, so 'org.eclipse.pde.feature' and 'org.eclipse.jdt.feature' are required by 'org.eclipse.sdk.ide'.

If the profile only has the STRICT rule for 'org.eclipse.sdk.ide', 'org.eclipse.jdt.feature' and 'org.eclipse.pdt.feature' will implicitly be updated to 3.6.2 when updating 'org.eclipse.sdk.ide' from 3.6.1 to 3.6.2.

However the profile has below STRICT rule for PDT feature,


<iuProperties id='org.eclipse.pdt.feature' version='3.6.1.M20100909-0800'>
      <properties size='2'>
        <property name='org.eclipse.equinox.p2.internal.inclusion.rules' value='STRICT'/>
      </properties>
</iuProperties>


The p2 engine will report errors due to 'org.eclipse.pdt.feature' has STRICT rule for updating. Hence third-party must explicitly update both 'org.eclipse.sdk.ide' and 'org.eclipse.pdt.feature' from 3.6.1 to 3.6.2.

Thursday, December 23, 2010

stack overflow protector

Latest gcc compiler enables the stack overflow protector that is since GLIBC 2.4. So the library or executable is compiled by latest gcc could be loaded or executed in RHEL4 or Solaris 9 that only have GLIBC 2.3. Hence using option '-fno-stack-protector' to compile the library or executable to make sure it could be executed in older linux release.

g++ -fno-stack-protector -o test.o test