May 18 2009

p2 and fragments

Published by at 9:58 pm under Eclipse,IT,Java

Recently I’m getting a bit confused about p2. There is an update site created with PDE headless build. There are IUs generated for each plug-in/fragment/feature. Everything looks great so far.

Let’s assume: plug-in A and fragment B with a defined host plug-in A are sitting together on single update site. Plug-in A in reality cannot run without appropriate version of fragment B (e.g. situation similar to SWT).

My understanding of p2-power was that I wouldn’t need to create separate feature C aggregating A and B just to make fragment B be automatically installed when I request installation of plug-in A.

I spent some time on reviewing Eclipse Bugzilla and mailing lists. Interesting findings:

http://wiki.eclipse.org/Equinox_p2_Meeting_2007#Fragments_optional_vs._requirement

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430

Any suggestions about handling such “required” fragment scenario without getting rid of autogenerated p2 repository and hand crafting p2 metadata?

2 responses so far

2 Responses to “p2 and fragments”

  1. Pascal Rapicaulton 19 May 2009 at 1:05 am

    There is no silver bullet here. p2 just can’t guess whether a fragment must be installed for a given plug-in. Early on we had tried various heuristics but this is not something that never worked. The only correct solution lies in having the IU for your plug-in express something about the mandatory fragments. For this there are two possibilities:
    1) The IU for the plug-in requires the IU of the fragments directly (using appropriate filters)
    2) The IU for the plug-in requires a capability that will be provided by each fragment.
    The main difference between 1) and 2) lies in whether or not a new fragment can be contributed without changing the IU for the plug-in.
    Now, how to do this? In both case you will have to play with the p2.inf and make sure you use the publisher application (which replaces the metadata generator).
    To implement case #1, the plug-in will have to have a p2.inf that will declare the dependencies on the fragments
    For example:
    requires.1.namespace=org.eclipse.equinox.p2.iu
    requires.1.name=fragment.for.windows
    requires.1.filter=(os=win32)
    requires.1.greedy=true
    requires.1.range=[1.0.0, 2.0.0)

    For additional fragments, simply change the middle digit.

    To implement case #2, the fragments will each have to have a p2.inf indicating the capability they provide
    provides.1.namespace=my.plugin
    provides.1.name=implementation.provider
    provides.1.version=1.0.0

    And the p2.inf for the plug-in will only have to have one requirement like the following one.
    requires.1.namespace=my.plugin
    requires.1.name=implementation.provider
    requires.1.filter=(os=win32)
    requires.1.greedy=true
    requires.1.range=[1.0.0, 2.0.0)

  2. Radoslaw Urbason 19 May 2009 at 3:22 pm

    Pascal – thanks for the information! Option #1 seems to meet my requirements.
    Now I’m trying to figure out how to integrate usage of org.eclipse.equinox.p2.publisher with PDE headless build.

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.