Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Unsatisfied version constraint
Unsatisfied version constraint [message #336138] Tue, 26 May 2009 08:10 Go to next message
Kai Schlamp is currently offline Kai Schlamp
Messages: 344
Registered: July 2009
Senior Member
Hello.

I am having some trouble with those "Unsatisfied version constraint" errors when using OSGI bundles
from the Spring resource site.
When for example I add the package org.h2.jdbcx (but only that package) of the bundle
com.springsource.org.h2 as dependency then I get an unsatified version constraint on
org.eclipse.core.runtime (but not when adding the package org.h2.jdbc of the same h2 bundle).
I am not very familiar with OSGI (and the dependeny stuff), but perhaps someone could shortly
explain that behavior to me (or provide a nice link) and how to solve it.
Re: Unsatisfied version constraint [message #336145 is a reply to message #336138] Tue, 26 May 2009 16:27 Go to previous messageGo to next message
Walter Harley is currently offline Walter Harley
Messages: 847
Registered: July 2009
Senior Member
"Kai Schlamp" <schlamp@gmx.de> wrote in message
news:gvg88f$5bd$1@build.eclipse.org...
> Hello.
>
> I am having some trouble with those "Unsatisfied version constraint"
> errors when using OSGI bundles from the Spring resource site.
> When for example I add the package org.h2.jdbcx (but only that package) of
> the bundle com.springsource.org.h2 as dependency then I get an unsatified
> version constraint on org.eclipse.core.runtime (but not when adding the
> package org.h2.jdbc of the same h2 bundle).
> I am not very familiar with OSGI (and the dependeny stuff), but perhaps
> someone could shortly explain that behavior to me (or provide a nice link)
> and how to solve it.

A bundle can express dependencies on various things, including its operating
platform (e.g., JDK version) and on other bundles. A bundle has a version
number, and can require specific versions or version ranges of the other
bundles it depends on. Each of those bundles in turn can require specific
versions or ranges of the bundles it depends on, and so forth.

A problem arises when conflicting requirements are encountered. For
instance, suppose:

bundle A v1.0.0 -> bundle B v2.1.0, bundle C v1.3.2
bundle B v2.1.0 -> bundle D v3.3.1
bundle C v1.3.2 -> bundle D v3.3.5

Assuming that bundle D is a singleton (as Eclipse plug-ins must be), there's
no way to satisfy these version constraints. Ideally, bundles B and C would
have been more lenient, for instance:

bundle A v1.0.0 -> bundle B v2.1.0, bundle C v1.3.2
bundle B v2.1.0 -> bundle D (v3.3.1-3.4.0]
bundle C v1.3.2 -> bundle D (v3.3.5-3.4.0]

in which case bundle D v3.3.5 would satisfy the requirements. However, if
those bundles are coming from elsewhere, you may be out of luck. There may
be a workaround for that (short of editing the dependent bundles'
manifests); I don't happen to know it.
Re: Unsatisfied version constraint [message #336171 is a reply to message #336138] Wed, 27 May 2009 19:38 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Kai Schlamp wrote:
> Hello.
>
> I am having some trouble with those "Unsatisfied version constraint"
> errors when using OSGI bundles from the Spring resource site.
> When for example I add the package org.h2.jdbcx (but only that package)
> of the bundle com.springsource.org.h2 as dependency then I get an
> unsatified version constraint on org.eclipse.core.runtime (but not when
> adding the package org.h2.jdbc of the same h2 bundle).
> I am not very familiar with OSGI (and the dependeny stuff), but perhaps
> someone could shortly explain that behavior to me (or provide a nice
> link) and how to solve it.

Are you certain that the versions of everything that you are trying to
install are known to be compatible with the Eclipse that you are
installing into? For example, sometimes people get the latest Eclipse
and try to install old third-party plug-ins into it which are not
compatible with the newer Eclipse. Something else that happens is that
people have an older Eclipse and try to install something new that
requires a newer Eclipse.
And then, as Walter explained, there are conflicting version issues that
can crop up, especially if a plug-in provider has been overly strict or
not careful in how he specifies dependencies.
Finally, if you're using Eclipse 3.4 the update mechanism (named p2) has
some pretty bad bugs when it comes to reporting problems to the user;
the error messages it spits out are very misleading and useless in
determining the actual cause of an installation problem. These issues
have been mostly addressed in Eclipse 3.5, by the way.

If you describe in more detail exactly what steps you are taking and
what you are seeing, we might be able to determine which of these
potential scenarios you are encountering...

Eric
Re: Unsatisfied version constraint [message #336172 is a reply to message #336145] Wed, 27 May 2009 19:43 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Walter Harley wrote:
>
> Assuming that bundle D is a singleton (as Eclipse plug-ins must be),

Strictly speaking, that is not really true. An Eclipse plug-in only has
to be a singleton if it declares either extensions or extension
point(s). In practical terms, not very many plug-ins will fall into that
category (the vast majority use extensions and/or extension points), but
it is possible.
The most common example seems to be plug-ins that only wrap a
third-party JAR (library) and expose its packages; those bundles don't
usually need extension points at all and thus do not have to be singletons.

Eric
Re: Unsatisfied version constraint [message #336177 is a reply to message #336172] Wed, 27 May 2009 22:36 Go to previous messageGo to next message
Eclipse User
Originally posted by: fraserofthenight.gmail.com

Eric Rizzo wrote:
> Walter Harley wrote:
>>
>> Assuming that bundle D is a singleton (as Eclipse plug-ins must be),
>
> Strictly speaking, that is not really true. An Eclipse plug-in only has
> to be a singleton if it declares either extensions or extension
> point(s). In practical terms, not very many plug-ins will fall into that
> category (the vast majority use extensions and/or extension points), but
> it is possible.
> The most common example seems to be plug-ins that only wrap a
> third-party JAR (library) and expose its packages; those bundles don't
> usually need extension points at all and thus do not have to be singletons.
>
> Eric

Is there a use to this?
Re: Unsatisfied version constraint [message #336185 is a reply to message #336171] Thu, 28 May 2009 11:40 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai Schlamp
Messages: 344
Registered: July 2009
Senior Member
Hy Eric,

thanks for your help.
I am working on the EMF/CDO source code.
CDO requires some database drivers that are (cause of some licensing issues)
not found in the Eclipse CVS, but are fetched by an ANT sript from the Spring
OSGI repository.
I work on a CDO H2 database integration, so want to use the H2 OSGI package from the Spring Repo.

But some OSGI packages from there lead to the mentioned problem.
For example the OSGI package com.springsource.com.mysql.jdbc makes auch trouble.
Below is a the Manifest of my bundle and that of the H2 bundle.

If I only import the "org.h2" package into my bundle everything is error free.
But as soon as I add the "org.h2.jdbcx" package I get:
"Unsatisfied version constraint: 'org.eclipse.net4j.db: [2.0.0,3.0.0)'"
and
"Unsatisfied version constraint: 'org.eclipse.core.runtime: [3.4.0,4.0.0)'"
And I don't see what this package (org.h2.jdbcx) has to do with those Eclipse bundles?!

I could easily avoid the problem by using the H2 bundle from the H2 site (and not the one
from the Spring Repository).
But I am just curious about why it is not working, and learn something about OSGi bundle dependencies.


My CDO bundle:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %pluginName
Bundle-SymbolicName: org.eclipse.net4j.db.h2;singleton:=true
Bundle-Version: 2.0.0.qualifier
Bundle-Vendor: %providerName
Bundle-Localization: plugin
Bundle-ClassPath: .
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
org.eclipse.net4j.db;bundle-version="[2.0.0,3.0.0)";visibility:=reexport
Export-Package: org.eclipse.net4j.db.h2;version="2.0.0",
org.eclipse.net4j.db.internal.h2.bundle;version="2.0.0";x-internal:=true
Eclipse-RegisterBuddy: org.eclipse.net4j.db
Bundle-ActivationPolicy: lazy
Bundle-Activator: org.eclipse.net4j.db.internal.h2.bundle.OM$Activator
Import-Package: org.h2;version="1.0.71",
org.h2.jdbcx;version="1.0.71"


The H2 OSGI bundel from Spring:

Manifest-Version: 1.0
Export-Package: org.h2;version="1.0.71",org.h2.api;version="1.0.71",or
g.h2.bnf;version="1.0.71";uses:="org.h2.server.web",org.h2.command;ve
rsion="1.0.71";uses:="org.h2.command.ddl,org.h2.engine,org.h2.express
ion,org.h2.result,org.h2.util",org.h2.command.ddl;version="1.0.71 ";us
es:=" org.h2.command,org.h2.command.dml,org.h2.engine,org.h2.expre ssio
n,org.h2.index,org.h2.result,org.h2.schema,org.h2.table",org.h2.comma
nd.dml;version="1.0.71";uses:="org.h2.command,org.h2.engine,org.h2.ex
pression,org.h2.result,org.h2.schema,org.h2.store,org.h2.tab le,org.h2
.util,org.h2.value",org.h2.compress;version="1.0.71",org.h2.constant;
version="1.0.71",org.h2.constraint;version="1.0.71";uses:= "org.h2.com
mand,org.h2.engine,org.h2.expression,org.h2.index,org.h2.res ult,org.h
2.schema,org.h2.table",org.h2.engine;version="1.0.71";uses:= "org.h2.a
pi,org.h2.command,org.h2.expression,org.h2.jdbc,org.h2.log,o rg.h2.mes
sage,org.h2.result,org.h2.schema,org.h2.store,org.h2.table,o rg.h2.uti
l,org.h2.value",org.h2.expression;version="1.0.71";uses:= "org.h2.comm
and,org.h2.command.dml,org.h2.engine,org.h2.result,org.h2.sc hema,org.
h2.table,org.h2.tools,org.h2.util,org.h2.value",org.h2.fulltext;versi
on="1.0.71";uses:="org.apache.lucene.index,org.h2.expression,org.h2.t
ools",org.h2.index;version="1.0.71";uses:="org.h2.engine,org.h2.expre
ssion,org.h2.result,org.h2.schema,org.h2.store,org.h2.table, org.h2.ut
il,org.h2.value",org.h2.jdbc;version="1.0.71";uses:="org.h2.command,o
rg.h2.engine,org.h2.message,org.h2.result,org.h2.util,org.h2 .value ",o
rg.h2.jdbcx;version="1.0.71";uses:="javax.naming,javax.sql,javax.tran
saction.xa,org.h2.jdbc,org.h2.message",org.h2.log;version="1.0.71 ";us
es:=" org.h2.engine,org.h2.result,org.h2.store,org.h2.table,org.h2 .uti
l",org.h2.message;version="1.0.71";uses:="org.h2.jdbc,org.h2.util ",or
g.h2.result;version="1.0.71";uses:="org.h2.engine,org.h2.expression,o
rg.h2.store,org.h2.util,org.h2.value",org.h2.schema;version= "1.0.71";
uses:=" org.h2.constraint,org.h2.engine,org.h2.expression,org.h2.ind ex
,org.h2.result,org.h2.table,org.h2.util,org.h2.value",org.h2.security
;version="1.0.71";uses:="org.h2.store",org.h2.server;version= "1.0.71"
,org.h2.server.ftp;version="1.0.71";uses:="org.h2.store.fs ",org.h2.se
rver.pg;version="1.0.71",org.h2.server.web;version="1.0.71 ";uses:="ja
vax.servlet,javax.servlet.http,org.h2.api,org.h2.bnf,org.h2. server ",o
rg.h2.store;version="1.0.71";uses:="org.h2.engine,org.h2.message,org.
h2.store.fs,org.h2.util,org.h2.value",org.h2.store.fs;version= "1.0.71
",org.h2.table;version="1.0.71";uses:="org.h2.command,org.h2.command.
dml,org.h2.constraint,org.h2.engine,org.h2.expression,org.h2 .index,or
g.h2.result,org.h2.schema,org.h2.store,org.h2.util,org.h2.va lue ",org.
h2.tools;version="1.0.71";uses:="org.h2.compress,org.h2.server,org.h2
.store,org.h2.util,org.h2.value",org.h2.util;version="1.0.71 ";uses:="
javax.sql,org.h2.jdbc,org.h2.store,org.h2.value",org.h2.value;version
="1.0.71";uses:="org.h2.engine,org.h2.jdbc,org.h2.store,org.h2.util "
Implementation-Title: H2 Database Engine
Bundle-Classpath: .
Implementation-Version: 1.0.71
Bundle-Name: H2 Database Engine
Created-By: 1.4.2_13-b06 (Sun Microsystems Inc.)
Implementation-URL: http://www.h2database.com
Bundle-Vendor: SpringSource
Bundle-Version: 1.0.71
Build-Jdk: 1.4
Bundle-ManifestVersion: 2
Import-Package: javax.naming,javax.naming.spi,javax.net,javax.net.ssl,
javax.servlet;version="[2.5.0, 3.0.0)";resolution:=optional,javax.ser
vlet.http;version="[2.5.0, 3.0.0)";resolution:=optional,javax.sql,jav
ax.transaction.xa;version="[1.0.1, 2.0.0)";resolution:=optional,org.a
pache.lucene.analysis;version="[2.3.0, 3.0.0)";resolution:=optional,o
rg.apache.lucene.analysis.standard;version="[2.3.0, 3.0.0)";resolutio
n:=optional,org.apache.lucene.document;version="[2.3.0, 3.0.0)";resol
ution:=optional,org.apache.lucene.index;version="[2.3.0, 3.0.0)";reso
lution:=optional,org.apache.lucene.queryParser;version="[2.3.0, 3.0.0
)";resolution:=optional,org.apache.lucene.search;version="[2.3.0, 3.0
.0)";resolution:=optional
Bundle-SymbolicName: com.springsource.org.h2
Main-Class: org.h2.tools.Console


Eric Rizzo wrote:
> Kai Schlamp wrote:
>> Hello.
>>
>> I am having some trouble with those "Unsatisfied version constraint"
>> errors when using OSGI bundles from the Spring resource site.
>> When for example I add the package org.h2.jdbcx (but only that
>> package) of the bundle com.springsource.org.h2 as dependency then I
>> get an unsatified version constraint on org.eclipse.core.runtime (but
>> not when adding the package org.h2.jdbc of the same h2 bundle).
>> I am not very familiar with OSGI (and the dependeny stuff), but
>> perhaps someone could shortly explain that behavior to me (or provide
>> a nice link) and how to solve it.
>
> Are you certain that the versions of everything that you are trying to
> install are known to be compatible with the Eclipse that you are
> installing into? For example, sometimes people get the latest Eclipse
> and try to install old third-party plug-ins into it which are not
> compatible with the newer Eclipse. Something else that happens is that
> people have an older Eclipse and try to install something new that
> requires a newer Eclipse.
> And then, as Walter explained, there are conflicting version issues that
> can crop up, especially if a plug-in provider has been overly strict or
> not careful in how he specifies dependencies.
> Finally, if you're using Eclipse 3.4 the update mechanism (named p2) has
> some pretty bad bugs when it comes to reporting problems to the user;
> the error messages it spits out are very misleading and useless in
> determining the actual cause of an installation problem. These issues
> have been mostly addressed in Eclipse 3.5, by the way.
>
> If you describe in more detail exactly what steps you are taking and
> what you are seeing, we might be able to determine which of these
> potential scenarios you are encountering...
>
> Eric
Re: Unsatisfied version constraint [message #336197 is a reply to message #336185] Thu, 28 May 2009 16:37 Go to previous messageGo to next message
Walter Harley is currently offline Walter Harley
Messages: 847
Registered: July 2009
Senior Member
"Kai Schlamp" <schlamp@gmx.de> wrote in message
news:gvlt9l$hgj$1@build.eclipse.org...
> [...]
> I could easily avoid the problem by using the H2 bundle from the H2 site
> (and not the one
> from the Spring Repository).

What's the difference in the manifests between the bundle on the H2 site and
the one on the Spring repo?
Re: Unsatisfied version constraint [message #336203 is a reply to message #336197] Fri, 29 May 2009 01:27 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai Schlamp
Messages: 344
Registered: July 2009
Senior Member
> What's the difference in the manifests between the bundle on the H2 site and
> the one on the Spring repo?

The manifest of the bundle from the H2 site is comparatively easy (see below).
But I still wonder, why only a imported package "org.h2.jdbcx" leads to a version constraint problem.
I also tried to delete 'uses:="javax.naming,javax.sql,javax.tran
saction.xa,org.h2.jdbc,org.h2.message"' from the manifest of the H2 Spring repository bundle, but
this also didn't solve the problem.
It would be nice if Eclipse would provide more information about that unsatisfied version constraint.


The manifest of the H2 bundle from the H2 site:

Manifest-Version: 1.0
Implementation-Title: H2 Database Engine
Implementation-URL: http://www.h2database.com
Implementation-Version: 1.1.113
Build-Jdk: 1.5
Created-By: 1.5.0_10-b03 (Sun Microsystems Inc.)
Main-Class: org.h2.tools.Console
Bundle-Activator: org.h2.util.DbDriverActivator
Bundle-ManifestVersion: 2
Bundle-Name: H2 Database Engine
Bundle-SymbolicName: org.h2
Bundle-Vendor: H2 Group
Bundle-Version: 1.1.113
DynamicImport-Package: *
Export-Package: org.h2,org.h2.api,org.h2.fulltext,org.h2.jdbcx,org.h2.tools, org.h2.util
Re: Unsatisfied version constraint [message #336216 is a reply to message #336177] Fri, 29 May 2009 19:24 Go to previous message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Robert Fraser wrote:
> Eric Rizzo wrote:
>> Walter Harley wrote:
>>>
>>> Assuming that bundle D is a singleton (as Eclipse plug-ins must be),
>>
>> Strictly speaking, that is not really true. An Eclipse plug-in only
>> has to be a singleton if it declares either extensions or extension
>> point(s). In practical terms, not very many plug-ins will fall into
>> that category (the vast majority use extensions and/or extension
>> points), but it is possible.
>> The most common example seems to be plug-ins that only wrap a
>> third-party JAR (library) and expose its packages; those bundles don't
>> usually need extension points at all and thus do not have to be
>> singletons.
>>
>> Eric
>
> Is there a use to this?

Well, by not being a singleton you are allowing Equinox to potentially
load multiple versions at the same time. Especially when it comes to
bundles that are just JAR wrappers, that seems like a very useful thing
to be able to do, when you need it.

Eric
Previous Topic:BasicNewFileResourceWizard
Next Topic:Wizard and getNextPage
Goto Forum:
  


Current Time: Sun Sep 21 10:11:45 GMT 2014

Powered by FUDForum. Page generated in 0.01949 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software