Home » Modeling » EMF » AdapterFactoryContentProvider and notifications
| | | | |
Re: AdapterFactoryContentProvider and notifications [message #416011 is a reply to message #416005] |
Wed, 16 January 2008 11:09 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Jan,
All that method does is check if the adapter list exists and if so, if
there are adapters in it. The idea is to ensure that the old question
"If a tree falls in the forest and there's no one there to hear it, does
it make a sound?" is answered with "no" it doesn't. Because in this
case, making a sound, i.e., creating and firing a notification, is
relatively expensive (extremely expensive compared to just setting the
value of a field), so doing so when there are no listeners, i.e., no
adapters, is avoided. The fact that there are no adapters on the
objects being changed implies to me that you didn't use an item provider
to gather the information you displayed in the view. Is your
ColumnLabelProvider delegating to AdapterFactoryLabelProvider or are you
implementing its methods directly?
Jan wrote:
> Ed,
>
> I'm using a org.eclipse.jface.viewers.ColumnLabelProvider. But I
> don'nt think that it is a labelprovider problem. All model objects are
> displayed correctly within the table! My problem is, that model
> changes (e.g. incrementing a value) are not noticed by the
> contentprovider. I think it might be a adapter problem because the
> eNotificationRequired() method within the models setters allways
> return false.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: AdapterFactoryContentProvider and notifications [message #416012 is a reply to message #416006] |
Wed, 16 January 2008 11:13 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Ron,
Good advice. I should have read it before posting my answer. Perhaps
EMF should have a utility class for this type of purpose, i.e, a
ColumnAdapterFactoryLabelProvider that takes a column index in the
constructor and delegates all the methods (we support color and font as
of today's build) to the columnIndex-based versions. The latest build
even includes a GenModel property, Table Providers, to generate the
right code to enable table column labels (as well as fonts and colors).
Ron Bermejo wrote:
> Jan wrote:
>
>> Ed,
>
>> I'm using a org.eclipse.jface.viewers.ColumnLabelProvider. But I
>> don'nt think that it is a labelprovider problem. All model objects
>> are displayed correctly within the table! My problem is, that model
>> changes (e.g. incrementing a value) are not noticed by the
>> contentprovider. I think it might be a adapter problem because the
>> eNotificationRequired() method within the models setters allways
>> return false.
>
> Hello, Jan!
>
> I suggest you use AdapterFactoryLabelProvider, this will set up the
> necessary adapters to your objects, as Ed mentioned.
>
> Since you are constrained to use CellLabelProvider by the JFace API,
> one way to do this would be to create a ColumnLabelProvider subclass
> that forwards the label requests to an appropriate
> AdapterFactoryLabelProvider member.
>
> For an example of this, you can check out the
> PropertyColumnLabelProvider inner class in this sample:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324 .
>
> Hth!
> Ron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Re: AdapterFactoryContentProvider and notifications [message #416017 is a reply to message #416015] |
Wed, 16 January 2008 12:14 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Tom,
Very cool. I've not even had time to explore using the data binding
support. :-( We need some nice EMF recipes for these things to help
people...
Tom Schindl wrote:
> Hi,
>
> This a problem the Databinding-Framework provides help and because of
> the great work going on in EMF to support this you can use it fairly
> easily or adapt the current implemetation for ColumnLabelProvider.
>
> In my applications setting up a Viewer looks like this:
>
>> final Addressbook book = Datasource.getInstance().getBook();
>> IObservableList list = EMFObservables.observeList(book,
>> MyPackage.Literals.ADDRESSBOOK__PEOPLE);
>>
>> final ChangeRecorder recorder = new ChangeRecorder();
>> recorder.beginRecording(Arrays.asList(book));
>>
>> ObservableListContentProvider cp = new
>> ObservableListContentProvider();
>> IObservableMap map =
>> EMFObservables.observeMap(cp.getKnownElements(),
>> MyPackage.Literals.PERSON__NAME);
>> ObservableMapLabelProvider lp = new
>> ObservableMapLabelProvider(map);
>>
>> EMFDataBindingContext ctx = new EMFDataBindingContext();
>>
>> viewer.setContentProvider(cp);
>> viewer.setLabelProvider(lp);
>> viewer.setInput(list);
>> IObservableValue value =
>> ViewersObservables.observeSingleSelection(viewer);
>
> This way you get a viewer which listens to all your model changes. The
> code above makes use of 2 JFace-Databinding classes
> (ObservableListContentProvider and ObservableMapLabelProvider). I have
> for my own projects written a subclass of ColumnLabelProvider [1].
>
> Using the databinding Framework has the advantage that it also deals
> with adding/removing of elements from your input-list (See the
> implementation of ObservableListContentProvider :-)
>
> Tom
>
> [1] http://publicsvn.bestsolution.at/repos/java/at.bestsolution. dataforms/trunk/src/at/bestsolution/dataforms/util/viewers/G enericObservableMapCellLabelProvider.java
>
>
> Ed Merks schrieb:
>> Ron,
>>
>> I'm pretty sure it's hooking up the adapter to the input to the table
>> viewer, but it won't hook them up to the children until the children
>> themselves are passed to the content or label provider methods. So I
>> think your previous advice is dead on the mark...
>>
>>
>> Ron Bermejo wrote:
>>> Jan wrote:
>>>
>>>> Ed,
>>>
>>>> I'm using a org.eclipse.jface.viewers.ColumnLabelProvider. But I
>>>> don'nt think that it is a labelprovider problem. All model objects
>>>> are displayed correctly within the table! My problem is, that model
>>>> changes (e.g. incrementing a value) are not noticed by the
>>>> contentprovider. I think it might be a adapter problem because the
>>>> eNotificationRequired() method within the models setters allways
>>>> return false.
>>>
>>> Hmm.. looking at it again.. it's a bit weird that the
>>> AdapterFactoryContentProvider didn't register adapters to your
>>> object. Perhaps you could put a breakpoint in
>>> AdapterFactoryContentProvider#getElements() (the very first time
>>> your object is adapted by the adapter factory), and trace from
>>> there.. (eventually it *should* call eAdapters().add())..
>>>
>>> Hth!
>>> Ron
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notifications [message #416087 is a reply to message #416015] |
Thu, 17 January 2008 13:40 |
Ron Bermejo Messages: 30 Registered: July 2009 |
Member |
|
|
Tom Schindl wrote:
> Hi,
> This a problem the Databinding-Framework provides help and because of
> the great work going on in EMF to support this you can use it fairly
> easily or adapt the current implemetation for ColumnLabelProvider.
> In my applications setting up a Viewer looks like this:
>> final Addressbook book = Datasource.getInstance().getBook();
>> IObservableList list = EMFObservables.observeList(book,
MyPackage.Literals.ADDRESSBOOK__PEOPLE);
>>
>> final ChangeRecorder recorder = new ChangeRecorder();
>> recorder.beginRecording(Arrays.asList(book));
>>
>> ObservableListContentProvider cp = new ObservableListContentProvider();
>> IObservableMap map = EMFObservables.observeMap(cp.getKnownElements(),
MyPackage.Literals.PERSON__NAME);
>> ObservableMapLabelProvider lp = new ObservableMapLabelProvider(map);
>>
>> EMFDataBindingContext ctx = new EMFDataBindingContext();
>>
>> viewer.setContentProvider(cp);
>> viewer.setLabelProvider(lp);
>> viewer.setInput(list);
>> IObservableValue value =
ViewersObservables.observeSingleSelection(viewer);
> This way you get a viewer which listens to all your model changes. The
> code above makes use of 2 JFace-Databinding classes
> (ObservableListContentProvider and ObservableMapLabelProvider). I have
> for my own projects written a subclass of ColumnLabelProvider [1].
> Using the databinding Framework has the advantage that it also deals
> with adding/removing of elements from your input-list (See the
> implementation of ObservableListContentProvider :-)
> Tom
>
[1] http://publicsvn.bestsolution.at/repos/java/at.bestsolution. dataforms/trunk/src/at/bestsolution/dataforms/util/viewers/G enericObservableMapCellLabelProvider.java
Hello, Tom & Ed.
Cool! :-)
With just a few lines of code (and Tom's label provider implementation) I
was able to modify the extlibrary sample editor to use EMF databinding:
createPages() {
...
// Create a page for the databinding table view.
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), ExtlibraryEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
return new TableViewer(composite,
SWT.MULTI | SWT.H_SCROLL |
SWT.V_SCROLL | SWT.BORDER | SWT.FULL_SELECTION);
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
tableViewer2 = (TableViewer)viewerPane.getViewer();
Table table = tableViewer2.getTable();
TableLayout layout = new TableLayout();
table.setLayout(layout);
table.setHeaderVisible(true);
table.setLinesVisible(true);
Library library = (Library)
getEditingDomain().getResourceSet().getResources().get(0).ge tContents().get(0);
TableViewerColumn viewerColumn;
IObservableMap[] maps;
// A content provider that listens to an IObservableList
ObservableListContentProvider cp = new ObservableListContentProvider();
tableViewer2.setContentProvider(cp);
// Name column
maps = EMFObservables.observeMaps(cp.getKnownElements(), new
EStructuralFeature[] {
ExtlibraryPackage.Literals.PERSON__LAST_NAME,
ExtlibraryPackage.Literals.PERSON__FIRST_NAME
});
viewerColumn = new TableViewerColumn(tableViewer2, SWT.LEAD);
viewerColumn.setLabelProvider(new
GenericObservableMapCellLabelProvider(maps, "{0}, {1}"));
viewerColumn.getColumn().setText("Last Name, First Name");
viewerColumn.getColumn().setWidth(200);
viewerColumn.getColumn().setMoveable(true);
// Address column
IObservableMap map = EMFObservables.observeMap(cp.getKnownElements(),
ExtlibraryPackage.Literals.ADDRESSABLE__ADDRESS);
viewerColumn = new TableViewerColumn(tableViewer2, SWT.LEAD);
viewerColumn.setLabelProvider(new
GenericObservableMapCellLabelProvider(map, "{0}"));
viewerColumn.getColumn().setText("Address");
viewerColumn.getColumn().setWidth(100);
viewerColumn.getColumn().setMoveable(true);
IObservableList list = EMFObservables.observeList(library,
ExtlibraryPackage.Literals.LIBRARY__BORROWERS);
tableViewer2.setInput(list);
createContextMenuFor(tableViewer2);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, "Databinding Table");
}
...
}
_____________
I can even re-order the columns and the display is correct :-)
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
java.lang.ClassCastException:
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$Containmen tUpdatingFeatureMapEntry
cannot be cast to org.eclipse.emf.ecore.EObject
at
org.eclipse.emf.databinding.EObjectObservableMap.hookListene r(EObjectObservableMap.java:62)
at
org.eclipse.core.databinding.observable.map.ComputedObservab leMap$1.handleSetChange(ComputedObservableMap.java:51)
at
org.eclipse.core.databinding.observable.set.SetChangeEvent.d ispatch(SetChangeEvent.java:61)
at
org.eclipse.core.databinding.observable.ChangeManager.fireEv ent(ChangeManager.java:128)
at
org.eclipse.core.databinding.observable.set.ObservableSet.fi reSetChange(ObservableSet.java:66)
at
org.eclipse.core.databinding.observable.set.WritableSet.addA ll(WritableSet.java:105)
at
org.eclipse.jface.databinding.viewers.ObservableListContentP rovider.setInput(ObservableListContentProvider.java:128)
at
org.eclipse.jface.databinding.viewers.ObservableListContentP rovider.inputChanged(ObservableListContentProvider.java:108)
at
org.eclipse.jface.viewers.ContentViewer.setInput(ContentView er.java:247)
________
So, my question is, how can I observe a feature which is of type
EFeatureMapEntry?
Thanks!
Ron
|
|
| |
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notifications [message #416091 is a reply to message #416087] |
Thu, 17 January 2008 14:44 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Ron,
I think I'd need to see a test case to track what's going wrong and to
fix it. I can't quite see how it ended up in map code given you showed
observing a list...
Ron Bermejo wrote:
> Tom Schindl wrote:
>
>> Hi,
>
>> This a problem the Databinding-Framework provides help and because of
>> the great work going on in EMF to support this you can use it fairly
>> easily or adapt the current implemetation for ColumnLabelProvider.
>
>> In my applications setting up a Viewer looks like this:
>
>>> final Addressbook book = Datasource.getInstance().getBook();
>>> IObservableList list = EMFObservables.observeList(book,
> MyPackage.Literals.ADDRESSBOOK__PEOPLE);
>>>
>>> final ChangeRecorder recorder = new ChangeRecorder();
>>> recorder.beginRecording(Arrays.asList(book));
>>>
>>> ObservableListContentProvider cp = new
>>> ObservableListContentProvider();
>>> IObservableMap map =
>>> EMFObservables.observeMap(cp.getKnownElements(),
> MyPackage.Literals.PERSON__NAME);
>>> ObservableMapLabelProvider lp = new
>>> ObservableMapLabelProvider(map);
>>>
>>> EMFDataBindingContext ctx = new EMFDataBindingContext();
>>>
>>> viewer.setContentProvider(cp);
>>> viewer.setLabelProvider(lp);
>>> viewer.setInput(list);
>>> IObservableValue value =
> ViewersObservables.observeSingleSelection(viewer);
>
>> This way you get a viewer which listens to all your model changes.
>> The code above makes use of 2 JFace-Databinding classes
>> (ObservableListContentProvider and ObservableMapLabelProvider). I
>> have for my own projects written a subclass of ColumnLabelProvider [1].
>
>> Using the databinding Framework has the advantage that it also deals
>> with adding/removing of elements from your input-list (See the
>> implementation of ObservableListContentProvider :-)
>
>> Tom
>
>>
> [1] http://publicsvn.bestsolution.at/repos/java/at.bestsolution. dataforms/trunk/src/at/bestsolution/dataforms/util/viewers/G enericObservableMapCellLabelProvider.java
>
>
>
> Hello, Tom & Ed.
>
> Cool! :-) With just a few lines of code (and Tom's label provider
> implementation) I was able to modify the extlibrary sample editor to
> use EMF databinding:
>
> createPages() {
> ...
> // Create a page for the databinding table view.
> {
> ViewerPane viewerPane =
> new ViewerPane(getSite().getPage(), ExtlibraryEditor.this) {
> @Override
> public Viewer createViewer(Composite composite) {
> return new TableViewer(composite,
> SWT.MULTI | SWT.H_SCROLL | SWT.V_SCROLL |
> SWT.BORDER | SWT.FULL_SELECTION);
> }
> @Override
> public void requestActivation() {
> super.requestActivation();
> setCurrentViewerPane(this);
> }
> };
> viewerPane.createControl(getContainer());
> tableViewer2 = (TableViewer)viewerPane.getViewer();
>
> Table table = tableViewer2.getTable();
> TableLayout layout = new TableLayout();
> table.setLayout(layout);
> table.setHeaderVisible(true);
> table.setLinesVisible(true);
>
> Library library = (Library)
> getEditingDomain().getResourceSet().getResources().get(0).ge tContents().get(0);
>
>
> TableViewerColumn viewerColumn;
> IObservableMap[] maps;
>
> // A content provider that listens to an IObservableList
> ObservableListContentProvider cp = new
> ObservableListContentProvider();
> tableViewer2.setContentProvider(cp);
>
> // Name column
> maps = EMFObservables.observeMaps(cp.getKnownElements(), new
> EStructuralFeature[] {
> ExtlibraryPackage.Literals.PERSON__LAST_NAME,
> ExtlibraryPackage.Literals.PERSON__FIRST_NAME
> });
>
> viewerColumn = new TableViewerColumn(tableViewer2, SWT.LEAD);
> viewerColumn.setLabelProvider(new
> GenericObservableMapCellLabelProvider(maps, "{0}, {1}"));
> viewerColumn.getColumn().setText("Last Name, First Name");
> viewerColumn.getColumn().setWidth(200);
> viewerColumn.getColumn().setMoveable(true);
>
> // Address column
> IObservableMap map =
> EMFObservables.observeMap(cp.getKnownElements(),
> ExtlibraryPackage.Literals.ADDRESSABLE__ADDRESS);
> viewerColumn = new TableViewerColumn(tableViewer2, SWT.LEAD);
> viewerColumn.setLabelProvider(new
> GenericObservableMapCellLabelProvider(map, "{0}"));
> viewerColumn.getColumn().setText("Address");
> viewerColumn.getColumn().setWidth(100);
> viewerColumn.getColumn().setMoveable(true);
>
> IObservableList list = EMFObservables.observeList(library,
> ExtlibraryPackage.Literals.LIBRARY__BORROWERS);
> tableViewer2.setInput(list);
>
> createContextMenuFor(tableViewer2);
> int pageIndex = addPage(viewerPane.getControl());
> setPageText(pageIndex, "Databinding Table");
> }
> ...
> }
>
> _____________
>
> I can even re-order the columns and the display is correct :-)
>
> 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
> java.lang.ClassCastException:
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$Containmen tUpdatingFeatureMapEntry
> cannot be cast to org.eclipse.emf.ecore.EObject
> at
> org.eclipse.emf.databinding.EObjectObservableMap.hookListene r(EObjectObservableMap.java:62)
>
> at
> org.eclipse.core.databinding.observable.map.ComputedObservab leMap$1.handleSetChange(ComputedObservableMap.java:51)
>
> at
> org.eclipse.core.databinding.observable.set.SetChangeEvent.d ispatch(SetChangeEvent.java:61)
>
> at
> org.eclipse.core.databinding.observable.ChangeManager.fireEv ent(ChangeManager.java:128)
>
> at
> org.eclipse.core.databinding.observable.set.ObservableSet.fi reSetChange(ObservableSet.java:66)
>
> at
> org.eclipse.core.databinding.observable.set.WritableSet.addA ll(WritableSet.java:105)
>
> at
> org.eclipse.jface.databinding.viewers.ObservableListContentP rovider.setInput(ObservableListContentProvider.java:128)
>
> at
> org.eclipse.jface.databinding.viewers.ObservableListContentP rovider.inputChanged(ObservableListContentProvider.java:108)
>
> at
> org.eclipse.jface.viewers.ContentViewer.setInput(ContentView er.java:247)
> ________
>
> So, my question is, how can I observe a feature which is of type
> EFeatureMapEntry?
>
> Thanks!
> Ron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #416109 is a reply to message #416091] |
Fri, 18 January 2008 09:58 |
Ron Bermejo Messages: 30 Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Ron,
> I think I'd need to see a test case to track what's going wrong and to
> fix it. I can't quite see how it ended up in map code given you showed
> observing a list...
Hi, Ed!
I tried to step through the code and this is what happens:
>> Library library = (Library)
>>
getEditingDomain().getResourceSet().getResources().get(0).ge tContents().get(0);
>>
>>
>> // A content provider that listens to an IObservableList
>> ObservableListContentProvider cp = new
>> ObservableListContentProvider();
>> tableViewer2.setContentProvider(cp);
>>
>> // Name column
>> maps = EMFObservables.observeMaps(cp.getKnownElements(), new
>> EStructuralFeature[] {
>> ExtlibraryPackage.Literals.PERSON__LAST_NAME,
>> ExtlibraryPackage.Literals.PERSON__FIRST_NAME
>> });
Two EObjectObservableMaps are created which track cp.getKnownElements()
(currently empty) as the set of keys.
>> // Address column
>> IObservableMap map =
>> EMFObservables.observeMap(cp.getKnownElements(),
>> ExtlibraryPackage.Literals.ADDRESSABLE__ADDRESS);
Same here...
>> IObservableList list = EMFObservables.observeList(library,
>> ExtlibraryPackage.Literals.LIBRARY__PEOPLE);
>> tableViewer2.setInput(list);
ObservableListContentProvider tries to populate cp.getKnownElements() set
with the entries from library.getPeople(). As these are populated, the
EObjectObservableMaps above get notified, and they try to hook themselves
into the objects being added.
Normally (when the attribute is an EList containing EObjects) this works
fine, but in this case the list contains FeatureMap.Entry objects.. The
hook code in EObjectObservableMap assumes EObjects and so a CCE exception
occurs.
protected void hookListener(Object domainElement)
{
((EObject)domainElement).eAdapters().add(elementListener);
}
When I tried to change it to:
protected void hookListener(Object domainElement)
{
if (domainElement instanceof FeatureMap.Entry) {
EObject eo = (EObject) ((FeatureMap.Entry) domainElement).getValue();
eo.eAdapters().add(elementListener);
} else {
((EObject)domainElement).eAdapters().add(elementListener);
}
}
it works ok. (I had to change to other methods similarly, too).
I don't know if EObjectObservableMap is really supposed to handle the case
of the key being a FeatureMap.Entry, or some unwrapping logic
(FeatureMap.Entry#getValue()) needs to be inserted outside... (but where?)
:-)
Cheers!
Ron
|
|
|
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #416111 is a reply to message #416109] |
Fri, 18 January 2008 11:28 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Ron,
It seems likely that feature maps need some special attention to unwrap
their values, particularly if, as I'm sure is typically the case, you'd
want to get at the underlying EObjects.
Ron Bermejo wrote:
> Ed Merks wrote:
>
>> Ron,
>
>> I think I'd need to see a test case to track what's going wrong and
>> to fix it. I can't quite see how it ended up in map code given you
>> showed observing a list...
>
> Hi, Ed!
>
> I tried to step through the code and this is what happens:
>
>>> Library library = (Library)
> getEditingDomain().getResourceSet().getResources().get(0).ge tContents().get(0);
>
>>>
>>> // A content provider that listens to an
>>> IObservableList
>>> ObservableListContentProvider cp = new
>>> ObservableListContentProvider();
>>> tableViewer2.setContentProvider(cp);
>>>
>>> // Name column
>>> maps = EMFObservables.observeMaps(cp.getKnownElements(), new
>>> EStructuralFeature[] {
>>> ExtlibraryPackage.Literals.PERSON__LAST_NAME,
>>> ExtlibraryPackage.Literals.PERSON__FIRST_NAME
>>> });
>
> Two EObjectObservableMaps are created which track
> cp.getKnownElements() (currently empty) as the set of
> keys.
>>> // Address column
>>> IObservableMap map =
>>> EMFObservables.observeMap(cp.getKnownElements(),
>>> ExtlibraryPackage.Literals.ADDRESSABLE__ADDRESS);
>
> Same here...
>
>>> IObservableList list = EMFObservables.observeList(library,
>>> ExtlibraryPackage.Literals.LIBRARY__PEOPLE);
>>> tableViewer2.setInput(list);
>
> ObservableListContentProvider tries to populate cp.getKnownElements()
> set with the entries from library.getPeople(). As these are populated,
> the EObjectObservableMaps above get notified, and they try to hook
> themselves into the objects being added.
>
> Normally (when the attribute is an EList containing EObjects) this
> works fine, but in this case the list contains FeatureMap.Entry
> objects.. The hook code in EObjectObservableMap assumes EObjects and
> so a CCE exception occurs.
I see. I've really never tested these things. It certain assumes the
domainElements are EObjects obviously....
>
> protected void hookListener(Object domainElement)
> {
> ((EObject)domainElement).eAdapters().add(elementListener);
> }
>
> When I tried to change it to:
> protected void hookListener(Object domainElement)
> {
> if (domainElement instanceof FeatureMap.Entry) {
> EObject eo = (EObject) ((FeatureMap.Entry)
> domainElement).getValue();
> eo.eAdapters().add(elementListener);
> } else {
> ((EObject)domainElement).eAdapters().add(elementListener);
> }
> }
I could imagine if you hooked up to say the mixed text feature of a
complex type you'd have some entries that hold simple values and some
that hold EObject...
>
> it works ok. (I had to change to other methods similarly, too).
>
> I don't know if EObjectObservableMap is really supposed to handle the
> case of the key being a FeatureMap.Entry, or some unwrapping logic
> (FeatureMap.Entry#getValue()) needs to be inserted outside... (but
> where?) :-)
It seems to me that everything should be handled gracefully. But as I
said in other notes in the group, I've really tested this stuff very
little. I told Boris I wasn't going to check in the map support because
I didn't understand how it was used. So he explained it to him and then
it made more sense, but that was a few months ago now. If you wanted to
send me a zipped up (exported) set of projects I could import to
reproduce the problem either in the newsgroup or to merks at ca dot ibm
dot com I'd have a look at fixing it in time for next week's build....
>
> Cheers!
> Ron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #416119 is a reply to message #416118] |
Fri, 18 January 2008 12:22 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Tom,
Comments below.
Tom Schindl wrote:
> Ed Merks schrieb:
>> Tom,
>>
>> A very good point indeed. I'd need to open a bugzilla anyway because
>> no line of code is committed without a bugzilla entry which allows us
>> to generate our release notes
>> http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=emf&version=HEAD
>> < http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=emf&version=HEAD>
>> that include a little link next to each bug which goes to the search
>> view http://www.eclipse.org/modeling/emf/searchcvs.php?q=215260 where
>> the link on the right of the entry goes to
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.edit/src/org/eclipse/em f/edit/provider/ItemProvider.java?root=Modeling_Project& r1=1.7&r2=1.8
>> < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.edit/src/org/eclipse/em f/edit/provider/ItemProvider.java?root=Modeling_Project& r1=1.7&r2=1.8>
>> which is an online diff view of the change. It's just too cool.
>> Never again do I have to personally and the question, what did you
>> change for this bugzilla nor even the question, what did you put in
>> this build or what build is this bugzilla in?
>>
>
> That's cool. Is this an EMF-build-system-only-feature ;-) because you
> are talking about builds I'm still not sure why you had to close my
> build.properties bug as WONTFIX.
This is the nick-o-matic build system that's used by much of the
modeling project and is being tailored for use by GEF as well as some
other new upstart projects. With regard to that bug you'd have to read
http://wiki.eclipse.org/EMF/Getting_Source#The_notorious_bug _109137
and well as https://bugs.eclipse.org/bugs/show_bug.cgi?id=109137 to
understand the painful contortions we must go through to bootstrap EMF
from a CVS image. The bottom line is that in order to compile generated
code, the libraries they use must be in jars so we are forced to go
through a step to build those jars. Of course these days one really
should be building jarred plugins, but that requires a full deploy step
where we want to be using the CVS-extracted EMF plugins both as projects
in the workspace as well as plugins in the IDE that's driving that
workspace. I often need to change the generator templates, exit
Eclipse, rebuild the jars, and start up again, and then regenerate the
code. So the thing that works best for us right now, is for the
MANIFEST.MF to specify a jar contained in the project into which we can
zip the contents of the bin folder. This of course doesn't produce the
right final thing for the official build so the nick-o-magic build tools
replace these things with "." and then the final result is a jarred
plugin. That's why the build.properties and the MANIFEST.MF are
inconsistent from your point of view. I understand that there is
working being done to fix the bug itself and then we'll be able to use
the same information that's generated for the runtime workspace to drive
the main Eclipse IDE, which we could actually do no, but the inability
to compile directly against the external bin folders prevents us. It's
kind of a long and old saga that's taken far too many years to address.
Of course I would help with addressing it, but my level of expertise in
the low level JDT, PDE, Resource API interactions just isn't
sufficiently deep.
>
> With the current build.properties one can't use the plugin (when
> checked out from CVS) in RCP-Applications but has to correct the
> build.properties first. It took me about an hour last time (and I know
> it will hit me the next time I start a new RCP-Application) to figure
> out why the hell my RCP-Application couldn't find EMFObservables
> because at compile time PDE didn't showed any errors. You'll only get
> them in runtime because the jar is missing in the bin.includes.
Yep. Sorry. I can only hope this problem goes away and that we can
have a nice clear bootstrapping process. This problem is of course not
unique to EMF but anyone building plugins against which generated code
must compile ends up with this same issue in the runtime workspace,
hence the 29 votes on the above bugzilla...
>
> Tom
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #418609 is a reply to message #416117] |
Tue, 22 April 2008 01:32 |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
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?
kind regards,
John
Ed Merks wrote:
> Tom,
>
> A very good point indeed. I'd need to open a bugzilla anyway because no
> line of code is committed without a bugzilla entry which allows us to
> generate our release notes
> http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=emf&version=HEAD
> < http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=emf&version=HEAD>
> that include a little link next to each bug which goes to the search
> view http://www.eclipse.org/modeling/emf/searchcvs.php?q=215260 where
> the link on the right of the entry goes to
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.edit/src/org/eclipse/em f/edit/provider/ItemProvider.java?root=Modeling_Project& r1=1.7&r2=1.8
> < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.edit/src/org/eclipse/em f/edit/provider/ItemProvider.java?root=Modeling_Project& r1=1.7&r2=1.8>
> which is an online diff view of the change. It's just too cool. Never
> again do I have to personally and the question, what did you change for
> this bugzilla nor even the question, what did you put in this build or
> what build is this bugzilla in?
>
>
>
> Tom Schindl wrote:
>> [...]
>>>> I don't know if EObjectObservableMap is really supposed to handle
>>>> the case of the key being a FeatureMap.Entry, or some unwrapping
>>>> logic (FeatureMap.Entry#getValue()) needs to be inserted outside...
>>>> (but where?) :-)
>>> It seems to me that everything should be handled gracefully. But as
>>> I said in other notes in the group, I've really tested this stuff
>>> very little. I told Boris I wasn't going to check in the map support
>>> because I didn't understand how it was used. So he explained it to
>>> him and then it made more sense, but that was a few months ago now.
>>> If you wanted to send me a zipped up (exported) set of projects I
>>> could import to reproduce the problem either in the newsgroup or to
>>> merks at ca dot ibm dot com I'd have a look at fixing it in time for
>>> next week's build....
>>>>
>>
>> Would it make more sense todo this in bugzilla, then I could attach
>> myself there and get informations about the progress.
>>
>> Tom
>>
>
|
|
| |
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #418622 is a reply to message #418612] |
Tue, 22 April 2008 13:18 |
Eric Rizzo Messages: 3070 Registered: July 2009 |
Senior Member |
|
|
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 #418623 is a reply to message #418622] |
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 #418626 is a reply to message #418623] |
Tue, 22 April 2008 14:10 |
Eric Rizzo Messages: 3070 Registered: July 2009 |
Senior Member |
|
|
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 #418627 is a reply to message #418623] |
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 #418632 is a reply to message #418622] |
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 #418633 is a reply to message #418623] |
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 #418634 is a reply to message #418627] |
Tue, 22 April 2008 15:17 |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Christian,
It not a singleton. Here's it's declaration:
Bundle-SymbolicName org.eclipse.core.databinding
John
Christian W. Damus wrote:
> 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 #418639 is a reply to message #418632] |
Tue, 22 April 2008 15:44 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Re: Databinding and EFeatureMap (Re: AdapterFactoryContentProvider and notificat [message #418649 is a reply to message #418639] |
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: Sun Apr 28 02:36:23 GMT 2024
Powered by FUDForum. Page generated in 0.06717 seconds
|