p2 and fragments

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 comments

  1. 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)

    Like

    1. 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.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s