Home » Eclipse Projects » Eclipse Platform » Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327496] |
Tue, 22 April 2008 13:18  |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Tom Schindl wrote:
> John E. Conlon schrieb:
>> Ed,
>>
>> While experimenting with EMF databinding, I ran into this issue as
>> well. Perhaps I missed it, but was a bugzilla opened on this
>> EFeatureMap issue?
>>
>> I'm still running 3.3.3 and EMF 2.3.2. From some of the conversations
>> on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>> I got the impression that I could just take the latest plugins and use
>> them with 2.3.2 so...
>>
>> I downloaded the
>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>> from
>> http://phoenix.eclipse.org/packages/
>> but the emf databinding plugins are not included!?
>>
>> So I downloaded the
>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>> the EMF databindings are in there, but there are dependencies on
>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>> and
>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>> preventing me from running on 3.3.3.
>>
>> So is it possible to run EMF databinding on 2.3.2 without sacrificing
>> too much functionality?
>>
>
> The emf-databinding plugin needs the databinding libs from 3.4 because
> of the missing move-method for lists in 3.3 but because core.databinding
> from 3.4 should be able to run on 3.3 as well all you'll need is to
> check out the core.databinding-project from cvs or copy it into your
> plugins-directory from a recent 3.4 build.
That will work for RCP apps or for an individual developer who controls
his own runtime, but what about those of us who are building plugins to
be installed into users' existing Eclipse environments? Is there any way
to make this work in 3.3 where we don't own the runtime (in other words,
where the user already has org.eclipse.core.databinding_1.0.x (as in
Europa)? Correct me if I'm wrong, but I don't think Equinox/OSGi can
handle multiple versions of the same plugin in the same runtime. Can it?
Eric
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327497 is a reply to message #327496] |
Tue, 22 April 2008 13:43  |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
I always thought that's exactly the reason why we all use OSGi.
A 1.0.0
A 1.1.0
B depends on A 1.0.0
C depends on A 1.1.0
If you don't set a version you'll the the newest.
Tom
Eric Rizzo schrieb:
> Tom Schindl wrote:
>> John E. Conlon schrieb:
>>> Ed,
>>>
>>> While experimenting with EMF databinding, I ran into this issue as
>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>> EFeatureMap issue?
>>>
>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the conversations
>>> on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>> I got the impression that I could just take the latest plugins and
>>> use them with 2.3.2 so...
>>>
>>> I downloaded the
>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>> from
>>> http://phoenix.eclipse.org/packages/
>>> but the emf databinding plugins are not included!?
>>>
>>> So I downloaded the
>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>> the EMF databindings are in there, but there are dependencies on
>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>> and
>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>> preventing me from running on 3.3.3.
>>>
>>> So is it possible to run EMF databinding on 2.3.2 without sacrificing
>>> too much functionality?
>>>
>>
>> The emf-databinding plugin needs the databinding libs from 3.4 because
>> of the missing move-method for lists in 3.3 but because
>> core.databinding from 3.4 should be able to run on 3.3 as well all
>> you'll need is to check out the core.databinding-project from cvs or
>> copy it into your plugins-directory from a recent 3.4 build.
>
> That will work for RCP apps or for an individual developer who controls
> his own runtime, but what about those of us who are building plugins to
> be installed into users' existing Eclipse environments? Is there any way
> to make this work in 3.3 where we don't own the runtime (in other words,
> where the user already has org.eclipse.core.databinding_1.0.x (as in
> Europa)? Correct me if I'm wrong, but I don't think Equinox/OSGi can
> handle multiple versions of the same plugin in the same runtime. Can it?
>
> Eric
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327498 is a reply to message #327497] |
Tue, 22 April 2008 14:10 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Tom Schindl wrote:
> I always thought that's exactly the reason why we all use OSGi.
>
> A 1.0.0
> A 1.1.0
>
>
> B depends on A 1.0.0
> C depends on A 1.1.0
>
> If you don't set a version you'll the the newest.
That's why I asked - my OSGi knowledge is minuscule and I'm glad to be
educated.
Thanks,
Eric
> Eric Rizzo schrieb:
>> Tom Schindl wrote:
>>> John E. Conlon schrieb:
>>>> Ed,
>>>>
>>>> While experimenting with EMF databinding, I ran into this issue as
>>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>>> EFeatureMap issue?
>>>>
>>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the
>>>> conversations on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>>> I got the impression that I could just take the latest plugins and
>>>> use them with 2.3.2 so...
>>>>
>>>> I downloaded the
>>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>>> from
>>>> http://phoenix.eclipse.org/packages/
>>>> but the emf databinding plugins are not included!?
>>>>
>>>> So I downloaded the
>>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>>> the EMF databindings are in there, but there are dependencies on
>>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>>> and
>>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>>> preventing me from running on 3.3.3.
>>>>
>>>> So is it possible to run EMF databinding on 2.3.2 without
>>>> sacrificing too much functionality?
>>>>
>>>
>>> The emf-databinding plugin needs the databinding libs from 3.4
>>> because of the missing move-method for lists in 3.3 but because
>>> core.databinding from 3.4 should be able to run on 3.3 as well all
>>> you'll need is to check out the core.databinding-project from cvs or
>>> copy it into your plugins-directory from a recent 3.4 build.
>>
>> That will work for RCP apps or for an individual developer who
>> controls his own runtime, but what about those of us who are building
>> plugins to be installed into users' existing Eclipse environments? Is
>> there any way to make this work in 3.3 where we don't own the runtime
>> (in other words, where the user already has
>> org.eclipse.core.databinding_1.0.x (as in Europa)? Correct me if I'm
>> wrong, but I don't think Equinox/OSGi can handle multiple versions of
>> the same plugin in the same runtime. Can it?
>>
>> Eric
>
>
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327499 is a reply to message #327497] |
Tue, 22 April 2008 14:23 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Tom,
A bundle can declare that it is a singleton, which indicates to OSGi that at
most one version of it may be resolved. Eclipse requires any bundle that
has extension points or extensions of others' points to be a singleton.
So, just double-check that your data binding bundles aren't singletons.
cW
Tom Schindl wrote:
> I always thought that's exactly the reason why we all use OSGi.
>
> A 1.0.0
> A 1.1.0
>
>
> B depends on A 1.0.0
> C depends on A 1.1.0
>
> If you don't set a version you'll the the newest.
>
> Tom
>
-----8<-----
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327501 is a reply to message #327496] |
Tue, 22 April 2008 14:50 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eric Rizzo wrote:
> Tom Schindl wrote:
>> John E. Conlon schrieb:
>>> Ed,
>>>
>>> While experimenting with EMF databinding, I ran into this issue as
>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>> EFeatureMap issue?
>>>
>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the conversations
>>> on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>> I got the impression that I could just take the latest plugins and
>>> use them with 2.3.2 so...
>>>
>>> I downloaded the
>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>> from
>>> http://phoenix.eclipse.org/packages/
>>> but the emf databinding plugins are not included!?
>>>
>>> So I downloaded the
>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>> the EMF databindings are in there, but there are dependencies on
>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>> and
>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>> preventing me from running on 3.3.3.
>>>
>>> So is it possible to run EMF databinding on 2.3.2 without sacrificing
>>> too much functionality?
>>>
>>
>> The emf-databinding plugin needs the databinding libs from 3.4 because
>> of the missing move-method for lists in 3.3 but because
>> core.databinding from 3.4 should be able to run on 3.3 as well all
>> you'll need is to check out the core.databinding-project from cvs or
>> copy it into your plugins-directory from a recent 3.4 build.
>
> That will work for RCP apps or for an individual developer who controls
> his own runtime, but what about those of us who are building plugins to
> be installed into users' existing Eclipse environments? Is there any way
> to make this work in 3.3 where we don't own the runtime (in other words,
> where the user already has org.eclipse.core.databinding_1.0.x (as in
> Europa)? Correct me if I'm wrong, but I don't think Equinox/OSGi can
> handle multiple versions of the same plugin in the same runtime. Can it?
>
> Eric
Yes! That is why OSGi is so cool.
But the manifest specifications for imports, exports, and require-bundle
have to match up to enable the OSGi runtime's wiring to setup the
correct versions.
This can get complicated when there are a lot of imports and exports. As
always tools help...
Check out the output we get from the OSGi bundle interrogation tool BND:
$ bnd print org.eclipse.core.databinding_1.1.0.I20080325-0100.jar
Using bnd version 0.0.130
Bundle-ActivationPolicy lazy
Bundle-Activator org.eclipse.core.internal.databinding.Activator
Bundle-ClassPath .
Bundle-Localization plugin
Bundle-ManifestVersion 2
Bundle-Name %pluginName
Bundle-RequiredExecutionEnvironmentJ2SE-1.4,CDC-1.0/Foundati on-1.0
Bundle-SymbolicName org.eclipse.core.databinding
Bundle-Vendor %providerName
Bundle-Version 1.1.0.I20080325-0100
Export-Package org.eclipse.core.databinding,
org.eclipse.core.databinding.conversion;x-internal:=false,
org.eclipse.core.databinding.observable,
org.eclipse.core.databinding.observable.list;x-internal:=fal se,
org.eclipse.core.databinding.observable.map,
org.eclipse.core.databinding.observable.masterdetail,
org.eclipse.core.databinding.observable.set;x-internal:=fals e,
org.eclipse.core.databinding.observable.value;x-internal:=fa lse,
org.eclipse.core.databinding.util,org.eclipse.core.databindi ng.validation;x-internal:=false,
org.eclipse.core.internal.databinding;x-friends:="org.eclipse.core.databinding.beans ",
org.eclipse.core.internal.databinding.conversion;x-friends:= "org.eclipse.jface.tests.databinding",
org.eclipse.core.internal.databinding.observable;x-internal: =true,
org.eclipse.core.internal.databinding.observable.masterdetai l;x-friends:= "org.eclipse.jface.tests.databinding",
org.eclipse.core.internal.databinding.observable.tree;x-frie nds:= " org.eclipse.jface.databinding,org.eclipse.jface.tests.databi nding ",
org.eclipse.core.internal.databinding.validation;x-friends:= "org.eclipse.jface.tests.databinding"
Import-Package com.ibm.icu.text
Manifest-Version 1.0
Require-Bundle
org.eclipse.core.runtime;bundle-version="
Bundle-ActivationPolicy lazy
Bundle-Activator
org.eclipse.emf.databinding.DataBindingPlugin$Implementation
Bundle-ClassPath .
Bundle-Localization plugin
Bundle-ManifestVersion 2
Bundle-Name %pluginName
Bundle-RequiredExecutionEnvironmentJ2SE-1.5
Bundle-SymbolicName org.eclipse.emf.databinding; singleton:=true
Bundle-Vendor %providerName
Bundle-Version 1.0.0.v200804012208
Eclipse-LazyStart true
Export-Package org.eclipse.emf.databinding
Manifest-Version 1.0
Require-Bundle
org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
org.eclipse.emf.ecore;visibility:=reexport;bundle-version="[2.4.0,3.0.0) ",
org.eclipse.core.databinding;visibility:=reexport;bundle-ver sion= "[1.1.0,2.0.0)"
and
$ bnd print org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
Using bnd version 0.0.130
[MANIFEST org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar]
Bundle-ActivationPolicy lazy
Bundle-Activator
org.eclipse.emf.databinding.edit.DataBindingEditPlugin$Imple mentation
Bundle-ClassPath .
Bundle-Localization plugin
Bundle-ManifestVersion 2
Bundle-Name %pluginName
Bundle-RequiredExecutionEnvironmentJ2SE-1.5
Bundle-SymbolicName org.eclipse.emf.databinding.edit;singleton:=true
Bundle-Vendor %providerName
Bundle-Version 1.0.0.v200804012208
Eclipse-LazyStart true
Export-Package org.eclipse.emf.databinding.edit
Manifest-Version 1.0
Require-Bundle
org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
org.eclipse.emf.databinding;visibility:=reexport;bundle-vers ion= "[1.0.0,2.0.0)",
org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
Just moving the EMF bundles do not work. Note the Require-Bundle spec
for both emf bundles for
org.eclipse.core.runtime;;bundle-version="[3.4.0,4.0.0)" and on the
org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
the Require-Bundle spec for
org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
Ed - Could the requirements for the runtime on both bundles be loosened
to [3.3.0,4.0.0) and the requirements for
org.eclipse.emf.edit be loosened to
[2.3.0,3.0.0)?
If so, then we could also use Import-Package instead of require-bundle
(always better if possible) on our bundles to specify the requirements
of our import packages to use the ones exported by 1.1.0.I20080325-0100
org.eclipse.core.databinding... packages.
Then in theory - Data binding for emf should be downward compatible with
Emf 2.3 and Eclipse 3.3.
John
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327503 is a reply to message #327497] |
Tue, 22 April 2008 15:07 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Tom Schindl wrote:
> I always thought that's exactly the reason why we all use OSGi.
>
> A 1.0.0
> A 1.1.0
>
>
> B depends on A 1.0.0
> C depends on A 1.1.0
>
> If you don't set a version you'll the the newest.
Not so sure. Don't recall seeing this behavior in the spec, so I think
it depends on what the runtime wants to do. The bundle may get the new
or the old. Always best to version both imports and exports.
>
> Tom
>
> Eric Rizzo schrieb:
>> Tom Schindl wrote:
>>> John E. Conlon schrieb:
>>>> Ed,
>>>>
>>>> While experimenting with EMF databinding, I ran into this issue as
>>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>>> EFeatureMap issue?
>>>>
>>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the
>>>> conversations on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>>> I got the impression that I could just take the latest plugins and
>>>> use them with 2.3.2 so...
>>>>
>>>> I downloaded the
>>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>>> from
>>>> http://phoenix.eclipse.org/packages/
>>>> but the emf databinding plugins are not included!?
>>>>
>>>> So I downloaded the
>>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>>> the EMF databindings are in there, but there are dependencies on
>>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>>> and
>>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>>> preventing me from running on 3.3.3.
>>>>
>>>> So is it possible to run EMF databinding on 2.3.2 without
>>>> sacrificing too much functionality?
>>>>
>>>
>>> The emf-databinding plugin needs the databinding libs from 3.4
>>> because of the missing move-method for lists in 3.3 but because
>>> core.databinding from 3.4 should be able to run on 3.3 as well all
>>> you'll need is to check out the core.databinding-project from cvs or
>>> copy it into your plugins-directory from a recent 3.4 build.
>>
>> That will work for RCP apps or for an individual developer who
>> controls his own runtime, but what about those of us who are building
>> plugins to be installed into users' existing Eclipse environments? Is
>> there any way to make this work in 3.3 where we don't own the runtime
>> (in other words, where the user already has
>> org.eclipse.core.databinding_1.0.x (as in Europa)? Correct me if I'm
>> wrong, but I don't think Equinox/OSGi can handle multiple versions of
>> the same plugin in the same runtime. Can it?
>>
>> Eric
>
>
|
|
|
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327504 is a reply to message #327501] |
Tue, 22 April 2008 15:44 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
John,
Comments below.
John E. Conlon wrote:
> Eric Rizzo wrote:
>> Tom Schindl wrote:
>>> John E. Conlon schrieb:
>>>> Ed,
>>>>
>>>> While experimenting with EMF databinding, I ran into this issue as
>>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>>> EFeatureMap issue?
>>>>
>>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the
>>>> conversations on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>>> I got the impression that I could just take the latest plugins and
>>>> use them with 2.3.2 so...
>>>>
>>>> I downloaded the
>>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>>> from
>>>> http://phoenix.eclipse.org/packages/
>>>> but the emf databinding plugins are not included!?
>>>>
>>>> So I downloaded the
>>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>>> the EMF databindings are in there, but there are dependencies on
>>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>>> and
>>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>>> preventing me from running on 3.3.3.
>>>>
>>>> So is it possible to run EMF databinding on 2.3.2 without
>>>> sacrificing too much functionality?
>>>>
>>>
>>> The emf-databinding plugin needs the databinding libs from 3.4
>>> because of the missing move-method for lists in 3.3 but because
>>> core.databinding from 3.4 should be able to run on 3.3 as well all
>>> you'll need is to check out the core.databinding-project from cvs or
>>> copy it into your plugins-directory from a recent 3.4 build.
>>
>> That will work for RCP apps or for an individual developer who
>> controls his own runtime, but what about those of us who are building
>> plugins to be installed into users' existing Eclipse environments? Is
>> there any way to make this work in 3.3 where we don't own the runtime
>> (in other words, where the user already has
>> org.eclipse.core.databinding_1.0.x (as in Europa)? Correct me if I'm
>> wrong, but I don't think Equinox/OSGi can handle multiple versions of
>> the same plugin in the same runtime. Can it?
>>
>> Eric
> Yes! That is why OSGi is so cool.
>
> But the manifest specifications for imports, exports, and
> require-bundle have to match up to enable the OSGi runtime's wiring to
> setup the correct versions.
>
> This can get complicated when there are a lot of imports and exports.
> As always tools help...
>
> Check out the output we get from the OSGi bundle interrogation tool BND:
>
> $ bnd print org.eclipse.core.databinding_1.1.0.I20080325-0100.jar
> Using bnd version 0.0.130
>
> Bundle-ActivationPolicy lazy
> Bundle-Activator
> org.eclipse.core.internal.databinding.Activator
> Bundle-ClassPath .
> Bundle-Localization plugin
> Bundle-ManifestVersion 2
> Bundle-Name %pluginName
> Bundle-RequiredExecutionEnvironmentJ2SE-1.4,CDC-1.0/Foundati on-1.0
> Bundle-SymbolicName org.eclipse.core.databinding
> Bundle-Vendor %providerName
> Bundle-Version 1.1.0.I20080325-0100
> Export-Package org.eclipse.core.databinding,
> org.eclipse.core.databinding.conversion;x-internal:=false,
> org.eclipse.core.databinding.observable,
> org.eclipse.core.databinding.observable.list;x-internal:=fal se,
> org.eclipse.core.databinding.observable.map,
> org.eclipse.core.databinding.observable.masterdetail,
> org.eclipse.core.databinding.observable.set;x-internal:=fals e,
> org.eclipse.core.databinding.observable.value;x-internal:=fa lse,
> org.eclipse.core.databinding.util,org.eclipse.core.databindi ng.validation;x-internal:=false,
>
> org.eclipse.core.internal.databinding;x-friends:="org.eclipse.core.databinding.beans ",
>
> org.eclipse.core.internal.databinding.conversion;x-friends:= "org.eclipse.jface.tests.databinding",
>
> org.eclipse.core.internal.databinding.observable;x-internal: =true,
> org.eclipse.core.internal.databinding.observable.masterdetai l;x-friends:= "org.eclipse.jface.tests.databinding",
>
> org.eclipse.core.internal.databinding.observable.tree;x-frie nds:= " org.eclipse.jface.databinding,org.eclipse.jface.tests.databi nding ",
>
> org.eclipse.core.internal.databinding.validation;x-friends:= "org.eclipse.jface.tests.databinding"
>
> Import-Package com.ibm.icu.text
> Manifest-Version 1.0
> Require-Bundle
> org.eclipse.core.runtime;bundle-version="
> Bundle-ActivationPolicy lazy
> Bundle-Activator
> org.eclipse.emf.databinding.DataBindingPlugin$Implementation
> Bundle-ClassPath .
> Bundle-Localization plugin
> Bundle-ManifestVersion 2
> Bundle-Name %pluginName
> Bundle-RequiredExecutionEnvironmentJ2SE-1.5
> Bundle-SymbolicName org.eclipse.emf.databinding; singleton:=true
> Bundle-Vendor %providerName
> Bundle-Version 1.0.0.v200804012208
> Eclipse-LazyStart true
> Export-Package org.eclipse.emf.databinding
> Manifest-Version 1.0
> Require-Bundle org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
> org.eclipse.emf.ecore;visibility:=reexport;bundle-version="[2.4.0,3.0.0) ",
>
> org.eclipse.core.databinding;visibility:=reexport;bundle-ver sion= "[1.1.0,2.0.0)"
>
>
> and
>
> $ bnd print org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
> Using bnd version 0.0.130
> [MANIFEST org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar]
> Bundle-ActivationPolicy lazy
> Bundle-Activator
> org.eclipse.emf.databinding.edit.DataBindingEditPlugin$Imple mentation
> Bundle-ClassPath .
> Bundle-Localization plugin
> Bundle-ManifestVersion 2
> Bundle-Name %pluginName
> Bundle-RequiredExecutionEnvironmentJ2SE-1.5
> Bundle-SymbolicName
> org.eclipse.emf.databinding.edit;singleton:=true
> Bundle-Vendor %providerName
> Bundle-Version 1.0.0.v200804012208
> Eclipse-LazyStart true
> Export-Package org.eclipse.emf.databinding.edit
> Manifest-Version 1.0
> Require-Bundle org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
> org.eclipse.emf.databinding;visibility:=reexport;bundle-vers ion= "[1.0.0,2.0.0)",
>
> org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
>
>
>
> Just moving the EMF bundles do not work. Note the Require-Bundle spec
> for both emf bundles for
> org.eclipse.core.runtime;;bundle-version="[3.4.0,4.0.0)" and on the
> org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
> the Require-Bundle spec for
> org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
>
> Ed - Could the requirements for the runtime on both bundles be
> loosened to [3.3.0,4.0.0) and the requirements for
> org.eclipse.emf.edit be loosened to
> [2.3.0,3.0.0)?
Firstly, I think because of changes related to this move issue thing, we
well might not work with Eclipse 3.3. A more fundamental issue is that
we don't hard code ranges in any of our plugins because of a religious
aversion I have to doing that. My reasons are as follows. An upper
bound in CVS is a pain in the neck. It's only a guess that something
might, could, or probably will go wrong at a higher version, but in
actual fact, typically nothing goes wrong and you have to sweep through
the code to change it to some bigger number. A lower bound is more
useful, but that's true if and only if you've actually confirmed it's
not simply stale information, i.e., if and only if you actually test
that the assertion is true. And who is actually testing that their
plugins work with older versions of Eclipse that they feel comfortable
making such a promise. So my assertion is that over time, Eclipse CVS
will fill up with bogus lower bounds. To avoid all this, we add ranges
as part of the build process. The lower bound is set to be x.y.0 when
we compile against a plugin with version x.y.z and the upper bound is
set to be x+1.0.0. This way our lower bound is definitely accurate,
because we've tested that combination, and our upper bound is quite
generous.
>
> If so, then we could also use Import-Package instead of require-bundle
> (always better if possible) on our bundles to specify the requirements
> of our import packages to use the ones exported by
> 1.1.0.I20080325-0100 org.eclipse.core.databinding... packages.
>
> Then in theory - Data binding for emf should be downward compatible
> with Emf 2.3 and Eclipse 3.3.
In theory, but I leave the practice to those willing to do the testing
for it...
>
> John
|
|
| | |
| Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #327507 is a reply to message #327504] |
Tue, 22 April 2008 17:57 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Ed,
See comments,
Ed Merks wrote:
> John E. Conlon wrote:
>> Eric Rizzo wrote:
>>> Tom Schindl wrote:
>>>> John E. Conlon schrieb:
>>>>> Ed,
>>>>>
>>>>> While experimenting with EMF databinding, I ran into this issue as
>>>>> well. Perhaps I missed it, but was a bugzilla opened on this
>>>>> EFeatureMap issue?
>>>>>
>>>>> I'm still running 3.3.3 and EMF 2.3.2. From some of the
>>>>> conversations on https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
>>>>> I got the impression that I could just take the latest plugins and
>>>>> use them with 2.3.2 so...
>>>>>
>>>>> I downloaded the
>>>>> eclipse-modeling-ganymede-M6-linux-gtk.tar.gz
>>>>> from
>>>>> http://phoenix.eclipse.org/packages/
>>>>> but the emf databinding plugins are not included!?
>>>>>
>>>>> So I downloaded the
>>>>> 2.4.0M6 (Tue, 1 Apr 2008 -- 22:08 (-0400))
>>>>> from http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>>>> the EMF databindings are in there, but there are dependencies on
>>>>> required bundle org.eclipse.core.databinding_[1.1.0,2.0.0).
>>>>> and
>>>>> required bundle org.eclipse.core.runtime_[3.4.0,4.0.0).
>>>>> preventing me from running on 3.3.3.
>>>>>
>>>>> So is it possible to run EMF databinding on 2.3.2 without
>>>>> sacrificing too much functionality?
>>>>>
>>>>
>>>> The emf-databinding plugin needs the databinding libs from 3.4
>>>> because of the missing move-method for lists in 3.3 but because
>>>> core.databinding from 3.4 should be able to run on 3.3 as well all
>>>> you'll need is to check out the core.databinding-project from cvs or
>>>> copy it into your plugins-directory from a recent 3.4 build.
>>>
>>> That will work for RCP apps or for an individual developer who
>>> controls his own runtime, but what about those of us who are building
>>> plugins to be installed into users' existing Eclipse environments? Is
>>> there any way to make this work in 3.3 where we don't own the runtime
>>> (in other words, where the user already has
>>> org.eclipse.core.databinding_1.0.x (as in Europa)? Correct me if I'm
>>> wrong, but I don't think Equinox/OSGi can handle multiple versions of
>>> the same plugin in the same runtime. Can it?
>>>
>>> Eric
>> Yes! That is why OSGi is so cool.
>>
>> But the manifest specifications for imports, exports, and
>> require-bundle have to match up to enable the OSGi runtime's wiring to
>> setup the correct versions.
>>
>> This can get complicated when there are a lot of imports and exports.
>> As always tools help...
>>
>> Check out the output we get from the OSGi bundle interrogation tool BND:
>>
>> $ bnd print org.eclipse.core.databinding_1.1.0.I20080325-0100.jar
>> Using bnd version 0.0.130
>>
>> Bundle-ActivationPolicy lazy
>> Bundle-Activator
>> org.eclipse.core.internal.databinding.Activator
>> Bundle-ClassPath .
>> Bundle-Localization plugin
>> Bundle-ManifestVersion 2
>> Bundle-Name %pluginName
>> Bundle-RequiredExecutionEnvironmentJ2SE-1.4,CDC-1.0/Foundati on-1.0
>> Bundle-SymbolicName org.eclipse.core.databinding
>> Bundle-Vendor %providerName
>> Bundle-Version 1.1.0.I20080325-0100
>> Export-Package org.eclipse.core.databinding,
>> org.eclipse.core.databinding.conversion;x-internal:=false,
>> org.eclipse.core.databinding.observable,
>> org.eclipse.core.databinding.observable.list;x-internal:=fal se,
>> org.eclipse.core.databinding.observable.map,
>> org.eclipse.core.databinding.observable.masterdetail,
>> org.eclipse.core.databinding.observable.set;x-internal:=fals e,
>> org.eclipse.core.databinding.observable.value;x-internal:=fa lse,
>> org.eclipse.core.databinding.util,org.eclipse.core.databindi ng.validation;x-internal:=false,
>>
>> org.eclipse.core.internal.databinding;x-friends:="org.eclipse.core.databinding.beans ",
>>
>> org.eclipse.core.internal.databinding.conversion;x-friends:= "org.eclipse.jface.tests.databinding",
>>
>> org.eclipse.core.internal.databinding.observable;x-internal: =true,
>> org.eclipse.core.internal.databinding.observable.masterdetai l;x-friends:= "org.eclipse.jface.tests.databinding",
>>
>> org.eclipse.core.internal.databinding.observable.tree;x-frie nds:= " org.eclipse.jface.databinding,org.eclipse.jface.tests.databi nding ",
>>
>> org.eclipse.core.internal.databinding.validation;x-friends:= "org.eclipse.jface.tests.databinding"
>>
>> Import-Package com.ibm.icu.text
>> Manifest-Version 1.0
>> Require-Bundle
>> org.eclipse.core.runtime;bundle-version="
>> Bundle-ActivationPolicy lazy
>> Bundle-Activator
>> org.eclipse.emf.databinding.DataBindingPlugin$Implementation
>> Bundle-ClassPath .
>> Bundle-Localization plugin
>> Bundle-ManifestVersion 2
>> Bundle-Name %pluginName
>> Bundle-RequiredExecutionEnvironmentJ2SE-1.5
>> Bundle-SymbolicName org.eclipse.emf.databinding; singleton:=true
>> Bundle-Vendor %providerName
>> Bundle-Version 1.0.0.v200804012208
>> Eclipse-LazyStart true
>> Export-Package org.eclipse.emf.databinding
>> Manifest-Version 1.0
>> Require-Bundle org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
>> org.eclipse.emf.ecore;visibility:=reexport;bundle-version="[2.4.0,3.0.0) ",
>>
>> org.eclipse.core.databinding;visibility:=reexport;bundle-ver sion= "[1.1.0,2.0.0)"
>>
>>
>> and
>>
>> $ bnd print org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
>> Using bnd version 0.0.130
>> [MANIFEST org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar]
>> Bundle-ActivationPolicy lazy
>> Bundle-Activator
>> org.eclipse.emf.databinding.edit.DataBindingEditPlugin$Imple mentation
>> Bundle-ClassPath .
>> Bundle-Localization plugin
>> Bundle-ManifestVersion 2
>> Bundle-Name %pluginName
>> Bundle-RequiredExecutionEnvironmentJ2SE-1.5
>> Bundle-SymbolicName
>> org.eclipse.emf.databinding.edit;singleton:=true
>> Bundle-Vendor %providerName
>> Bundle-Version 1.0.0.v200804012208
>> Eclipse-LazyStart true
>> Export-Package org.eclipse.emf.databinding.edit
>> Manifest-Version 1.0
>> Require-Bundle org.eclipse.core.runtime;bundle-version="[3.4.0,4.0.0)",
>> org.eclipse.emf.databinding;visibility:=reexport;bundle-vers ion= "[1.0.0,2.0.0)",
>>
>> org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
>>
>>
>>
>> Just moving the EMF bundles do not work. Note the Require-Bundle spec
>> for both emf bundles for
>> org.eclipse.core.runtime;;bundle-version="[3.4.0,4.0.0)" and on the
>> org.eclipse.emf.databinding.edit_1.0.0.v200804012208.jar
>> the Require-Bundle spec for
>> org.eclipse.emf.edit;visibility:=reexport;bundle-version="[2.4.0,3.0.0) "
>>
>> Ed - Could the requirements for the runtime on both bundles be
>> loosened to [3.3.0,4.0.0) and the requirements for
>> org.eclipse.emf.edit be loosened to
>> [2.3.0,3.0.0)?
> Firstly, I think because of changes related to this move issue thing, we
> well might not work with Eclipse 3.3. A more fundamental issue is that
> we don't hard code ranges in any of our plugins because of a religious
> aversion I have to doing that.
These days one must respect the diversities of religious and scientific
beliefs ;-)
My reasons are as follows. An upper
> bound in CVS is a pain in the neck. It's only a guess that something
> might, could, or probably will go wrong at a higher version, but in
> actual fact, typically nothing goes wrong and you have to sweep through
> the code to change it to some bigger number. A lower bound is more
> useful, but that's true if and only if you've actually confirmed it's
> not simply stale information, i.e., if and only if you actually test
> that the assertion is true.
Agree.
And who is actually testing that their
> plugins work with older versions of Eclipse that they feel comfortable
> making such a promise. So my assertion is that over time, Eclipse CVS
> will fill up with bogus lower bounds. To avoid all this, we add ranges
> as part of the build process. The lower bound is set to be x.y.0 when
> we compile against a plugin with version x.y.z and the upper bound is
> set to be x+1.0.0. This way our lower bound is definitely accurate,
> because we've tested that combination, and our upper bound is quite
> generous.
There is only so much testing one can do. I agree testing for lower
level compatibility is that much more of a hassle. Well I had my fingers
crossed that it was at least possible, but after I did not see specs in
the cvs and I saw them in the built artifact that using a 3.4 lower
level was a pragmatic decision based on these reasons.
>>
>> If so, then we could also use Import-Package instead of require-bundle
>> (always better if possible) on our bundles to specify the requirements
>> of our import packages to use the ones exported by
>> 1.1.0.I20080325-0100 org.eclipse.core.databinding... packages.
>>
>> Then in theory - Data binding for emf should be downward compatible
>> with Emf 2.3 and Eclipse 3.3.
> In theory, but I leave the practice to those willing to do the testing
> for it...
You know the old saying.
In theory: practice and theory are the same.
In practice: they aren't.
In practice (ie for practitioners that will do their own 3.3
computability testing with EMF databinding like myself and Eric?)...
If you want to get the latest databinding functionality from EMF
working (See Caveat1 below) with an existing 3.3 Eclipse and 2.3 Runtime.
You (or your clients) will have to add the latest 1.1.0.I20080325-0100
org.eclipse.core.databinding to the plugins directory. But you will have
to build your own emf.databinding and emf.databinding.edit plugins.
To do that checkout the latest code from EMF head (Caveat2 keep your
fingers crossed that nothing other than specifications in the manifest
are incompatible - and continue to test as everything moves forward
toward release).
For now -simpling changing the Require-Bundle on the
org.eclipse.emf.databinding to
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.emf.ecore;visibility:=reexport,
org.eclipse.core.databinding;bundle-version="[1.1.0,1.2.0)";visibility:=reexport
(you'll have to fix any issues in the build.properties files as well)
....seems to work (except for Caveat1 below)
(If you don't want to deal with cvs from the head, I think you can use
the BND tool to operate directly on the 2.4 EMF databinding bundles and
get it to produce bundles with different manifests.)
Caveat1: Back to where this thread offspring started...
When I test the latest databinding code from the Head with 3.2 and 2.4
in the manner described above.
I am still getting the same exception as Ron's:
> However, when I try to observe LIBRARY__PEOPLE (which is a FeatureMap containing LIBRARY__BORROWERS and LIBRARY__EMPLOYEES) instead of just LIBRARY__BORROWERS, I get some runtime error ...
>
> // code is same as above except this line:
> IObservableList list = EMFObservables.observeList(library, ExtlibraryPackage.Literals.LIBRARY__PEOPLE);
>
>
> !ENTRY org.eclipse.ui 4 0 2008-01-17 21:37:25.043
> !MESSAGE Unable to create editor ID org.example.extlibrary.presentation.ExtlibraryEditorID: org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$Containmen tUpdatingFeatureMapEntry cannot be cast to org.eclipse.emf.ecore.EObject
> !STACK 0 ...
Has this EFeatureMap cast error been bugzillaed someplace or is this an
I/O (ignorant operator) error on my part?
John
|
|
|
Goto Forum:
Current Time: Thu Dec 26 16:30:36 GMT 2024
Powered by FUDForum. Page generated in 0.03577 seconds |
] 
Search
Help
Register
Login
Home
