Re: [p2-dev] Question about non-greedy optional dependencies

[Andrew Eisenberg <andrew@xxxxxxxxxxxx>]

Hi all,

An update here, I am having some trouble with this.  greedy=true is
not being respected during an update.

If I add the update site: http://m2eclipse.sonatype.org/sites/m2e/ and
then perform any p2 update/install operation (eg- installing DLTK)
with "Contact all update sites..." checked, some bundles of
org.maven.ide.eclipse will be installed even though I do not want them
to be.

I created a p2.inf file that gets shipped with the appropriate bundle.
 The p2.inf file is recognized during the build, but not at runtime.
Here are the contents of my p2.inf file.  Do you see any obvious
problems with it?

# Specify all m2e bundles as optional as well as non-greedy
requires.0.namespace=osgi.bundle
requires.0.name=org.maven.ide.eclipse
requires.0.range=[0.0.0,9.9.9]
requires.0.greedy=false
requires.0.optional=true

requires.1.namespace=osgi.bundle
requires.1.name=org.maven.ide.eclipse.launching
requires.1.range=[0.0.0,9.9.9]
requires.1.greedy=false
requires.1.optional=true

requires.2.namespace=osgi.bundle
requires.2.name=org.maven.ide.eclipse.maven_embedder
requires.2.range=[0.0.0,9.9.9]
requires.2.greedy=false
requires.2.optional=true

requires.3.namespace=osgi.bundle
requires.3.name=org.maven.ide.eclipse.jdt
requires.3.range=[0.0.0,9.9.9]
requires.3.greedy=false
requires.3.optional=true

And here is the contents of the MANIFEST.MF for the bundle:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %pluginName
Bundle-SymbolicName: com.springsource.sts.maven.legacy;singleton:=true
Bundle-Version: 2.8.0.qualifier
Bundle-Activator: com.springsource.sts.maven.legacy.MavenCorePlugin
Bundle-Vendor: %providerName
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 org.eclipse.core.resources,
 org.eclipse.jdt.core,
 org.eclipse.debug.core,
 org.eclipse.debug.ui,
 org.eclipse.jdt.launching,
 org.eclipse.ui,
 org.eclipse.ui.ide,
 org.springframework.ide.eclipse.ui,
 org.springframework.ide.eclipse.core,
 com.springsource.sts.ide.configurator,
 org.maven.ide.eclipse;resolution:=optional;bundle-version="0.12.0.20101115-1102",
 org.maven.ide.eclipse.launching;resolution:=optional,
 org.maven.ide.eclipse.maven_embedder;resolution:=optional;bundle-version="0.12.0.20101115-1102",
 org.maven.ide.eclipse.jdt;resolution:=optional;bundle-version="0.12.0.20101115-1102",
 org.datanucleus.ide.eclipse;resolution:=optional,
 org.springframework.core;bundle-version="[3.0.5.RELEASE,3.2.0)",
 org.springframework.beans;bundle-version="[3.0.5.RELEASE,3.2.0)"
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Eclipse-LazyStart: true
Bundle-ActivationPolicy: lazy
Bundle-Localization: plugin
Export-Package: com.springsource.sts.maven.legacy



To be a little more concrete here, I am trying to ensure that our
product supports both the new and old versions of m2eclipse.  So, we
need to release one bundle for each version of m2eclipse that we are
supporting.  We also need to ensure that there are no pieces of the
wrong version of m2eclipse installed, which (theoretically, at least)
setting greedy=false should prevent.

Thanks for your help,
Andrew


On Fri, Nov 4, 2011 at 10:12 PM, Andrew Eisenberg <andrew@xxxxxxxxxxxx> wrote:
> I know that it is possible to disable greedy installation of optional
> dependencies
> by following instructions here:
> http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata#Capability_Advice:
>
> My question follows from this scenario.
>
> Let's say I start with 3 bundles called:
> com.required
> com.non-greedy-optional
> com.non-optional
>
> com.non-optional has a non-optional dependency on com.required.
> com.non-greedy-optional has a non-greedy optional dependency on com.required.
>
> Let's say that I uninstall com.non-optional.
>
> What will happen to com.required?  Will it stick around because of the
> optional dependency coming from com.non-greedy-optional?  But, since
> the dependency is non-greedy, would that mean that com.required would
> be uninstalled?
>
> I am going to try this out, but since there is a very long feedback
> loop between setting up the p2.inf files and getting a build back that
> I can try, I was hoping to hear back from someone to see what behavior
> I should be expecting.  Thanks.
>
> Andrew
>