Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] package resolver bugs? PDE bugs?


PDE relelated questions should be posted to the pde-dev mailing list or news group.

PDE uses the same selection policy which the runtime will use.  This is to pick the highest available version for the package.  You may consider opening an enhancement bug against PDE->UI to adjust the selection policy on the version.  I don't think PDE will be willing to change the default to pick the lowest version first though ...

The example projects work for me on M5 (the highest package version does get picked).  It seemed one of your Activator classes was not compiling becuase the class is missing an import org.osxa.pdetest.*; statement.

Tom





Harald Niesche <harald@xxxxxxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/22/2006 06:46 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
[equinox-dev] package resolver bugs? PDE bugs?






Consider a workspace with four bundles:

 org.osxa.pdetestExport1
   -- export org.osxa.pdetest // no version=, implying version=0.0.0
      -- contains IAmAnInterface

 org.osxa.pdetestExport1
   -- export org.osxa.pdetest;version="2.7"
      -- contains IAmAnInterface, AmAnImplementation

 org.osxa.pdetestImport1
   -- import org.osxa.pdetest
                      // no version=, implying version=[0.0.0, oo)
      -- activator uses IAmAnInterface, AmAnImplementation

 org.osxa.pdetestImport2
   -- import org.osxa.pdetest;version="0.0.0"
                      // equivalent to version=[0.0.0, oo)
      -- activator uses IAmAnInterface, AmAnImplementation


---

Both Import1 and Import2 use an interface and it's implementation,
the interface exists in both Export1 and Export2, the implementation
is available only in Export2.

Since both Import1 and Import2 import the same package, I'd expect
them both to find the interface and to maybe find the implementation class.

But in the PDE, Import1 finds neither while Import2 finds both.

Finding both is legal (in the OSGi framework "An exporter with a higher
version is preferred over an exporter with a lower version"), but in the
PDE I'd expect the import to be wired to the *lowest* matching export
(because that helps check whether the version constraint is truthful).

Finding none for Import1 should definitely  be a bug, because not
specifying the version constraint should be equivalent to asking for
version=0.0.0 which is a shortcut for version="[0.0.0, oo)" (which
couldn't be specified, anyway, because the "infinity" symbol is not
legal in a Manifest header),

The problem is made more serious by the fact that the PDE resolver seems
to consider disabled plugins that exist in the Target Platform to be
viable exporters (and that means I have only one bundle in my workspace
that exports a package but it can't be found because a *disabled* bundle
also exports the same package but without a version constraint, it
happened to me with the javax.servlet package).

Another problem is that when these bundles are run in Equinox, the
equinox resolver seems to wire both Export1 and Export2 to the classes
exported by Export2, which is illegal in OSGi R4 (the bundles specify
the "Bundle-ManifestVersion: 2" header), because an Export-Package: no
longer implies an Import-Package: for the same packages.

I couldn't find any entries for these in bugzilla.

Are they bugs?



Harald

PS: The workspace demonstrating the problem is available at
http://osxa.org/downloads/hn3000/workspace-pde-bug.zip

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top