Bug 82517

Comment 1 Mike . 2005-01-15 02:27:48 EST

src/.../model/ediagram.genmodel refers to a "src-ecore" directory in the
o.e.emf.ecore project, which doesn't exist.  Specifically:

usedGenPackages="../../../../../../../../org.eclipse.emf.ecore/src-ecore/model/Ecore.genmodel#//ecore"

Ideas on why this is?

Comment 2 Pratik Shah 2005-01-18 11:55:39 EST

Import the org.eclipse.emf.ecore plug-in in your workspace with source.

As described in Bug 72215, this is a known problem with EMF.

Comment 3 Randy Hudson 2005-03-21 16:55:30 EST

not for 3.1

Comment 4 Pratik Shah 2005-05-13 01:49:29 EDT

Let's keep helpwanted bugs open (they don't show up from the website link 
otherwise).

Ed, we'll take any changes that are justified and are improvements.  Just make 
sure we discuss them on here before you make the changes.

As for Java generics, it's better to stay away from them, at least for now.  
Eclipse and GEF don't officially support JRE 1.5 yet and we can't require that 
of our clients.

Comment 5 Ed Willink 2005-05-13 16:34:42 EDT

An interesting list. Perhaps half concern me or seem easy to fix.

Ediagram is an editor for a view (.ediagram) of a meta-model (.ecore).
My additional requirement is for a view (.umlx) of a pattern (.ucore)
of elements from a meta-model (.ecore), where (.ucore) is my prototype
QVT meta-model. The extra level of indirection requires better and
more extensive ergonomics, but most notably, distinctly more graphical
elements, some of which have different semnatics when appearing in a
pattern and a meta-model. So I really need to split the underlying support
from the diagram-specific content policies.

> Ed, we'll take any changes that are justified and are improvements.
> Just make sure we discuss them on here before you make the changes.

Does this mean that you propose to register me as a committer for ediagram?

Hitherto, I have been trying hard to avoid editing Ediagram so that I can
easily track your fixes by simple CVS monitoring. I have recently unwound
some of my changes that ensured that requests could activate diagram element
specific behaviour from the creation factories. This imposed too many
difficulties in ensuring that the appropriate derived request got constructed.
I seem to be getting on much better by introducing a new tree of singleton
policy classes that inherit from IRegime. These are appropriately used from
the creation factory by the artifice of defining an IRegime as the
getNewObjectType(). As stateless singletons, they are readily accessed in
other contexts and activated by an extension point. The IRegimes have much
in common with EditPolicys, but EditPolicy carries a large amount of stateful
graphical editing baggage. It therefore seems beneficial to delegate the
model rather than graphic dependent policy from EditPolicy to the appropriate
IRegime.

In order to give consistent response to class names, I find I need all names
to exist, so I have to augment NamedElementView with DataTypeView, ClassView
etc. I have a .ediagram that defines all these. The extra class names are a
breaking change, unless the EMF reader is enhanced to provide compatibility.
Introduction of AttributeView provides the place for isShown annotations
to be activated and display arrangements to be maintained.

I have yet to discover whether it is trivial to ensure that a derived
getENamedElement() can be made to refer to the derived ENamedElement. I suspect
it is, but isDerived is not in the EMF book. Any clues?

Re generics. It is perhaps too early for GEF to use generics. It is perhaps
too soon for EDiagram to use generics since EMF does not use generics. On the
other hand, generics is a compile time only facility, so it does not impose
on anyone just using libraries. EDiagram has yet to be released, so there is
no compatibility issue. I find it very convenient to have

BaseEditPart<V extends DiagramElement, M extends EObject, F extends IFigure>
CreateNodeCommand<M extends EObject, V extends Node>
CreateLinkCommand<M extends EObject, S extends Node, V extends Link, T extends Node>

since they eliminate nearly all casts (and detected a number of type errors).

However, if this really is a problem, I can probably organise things so
that the neutral support is typeless, my non-GEF diagrams are generic,
and perhaps EDiagram is non-generic.

I'm off on holiday now for a week. I hope to have a coherent view of quite what
I need to change in two weeks time.

Comment 6 Randy Hudson 2005-05-13 22:59:31 EDT

The goals of the eDiagram example are:
1) To be a UML-ish GEF example
2) To demonstrate split models (view and business)
3) To provide some level of an ecore editor for EMF users

Ed, what are your goals? What are you trying to do with/to the example? The 
example is _not_ a supported extensible framework currently. You should check 
out the proposed GMF project.

Comment 7 Ed Willink 2005-05-22 08:31:51 EDT

My goal is to provide a comprehensive editing/execution/debugging environment
for the UMLX graphical transformation language. This is an extension of the
MOF (meta-modelling) subset of UML to support model-to-model transformations.

(See http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/gmt-
home/doc/umlx/SCICO2003.pdf for description plus example pictures)

I therefore need an ability to edit meta-models (pictures of relations
between classes and attributes); EDiagram is very close here.

I also need an ability to edit patterns (pictures of relations between
class instances, attribute instances and attribute values). 

I very much hope that GMF will facilitate this, but I doubt that a stable
GMF will be ready for use for a year.

I want to progress with this now, so I would like EDiagram to be extensible
now. It is inconvenient to maintain a rival EDiagram as part of UMLX, so
I would prefer to contribute to an extensible evolution of EDiagram within GEF,
and to its eventual replacement by GMF.

Comment 8 Randy Hudson 2005-05-23 13:10:09 EDT

> It is inconvenient to maintain a rival EDiagram as part of UMLX

You are assuming that the example is changing frequently?  I don't think it 
will change much at all after the 3.1 release.

Comment 9 Ed Willink 2005-05-23 14:25:01 EDT

No assumption. If the standard GEF EDiagram is instanceof based, and my
variant is extension point and IRegime based, then these are rival versions.
I would like to avoid this.

Comment 10 Pratik Shah 2005-06-08 01:01:26 EDT

Adding to the list of missing functionality: SnapToGeometry can be quite 
useful in this example.

Comment 11 Pratik Shah 2005-06-08 01:14:43 EDT

Since, it's very easy to do, I've added the snap to geometry feature.

~DiagramEditPart

Comment 12 Pratik Shah 2005-06-08 02:37:32 EDT

A couple of other minor changes:

- Shift+Del is permanent delete now (~EDiagramEditor)
- Mod1+MouseWheel is zooming now (instead of Ctrl+MouseWheel) (~EDiagramEditor)
- When a superclass is renamed, the subclass updates in the outline to show 
this (~ClassifierTreeEditPart)

Additional bugs noticed:
- When you permanently delete a class, there's no way left to delete any 
references to it (they're in the outline, but not in the view anymore -- and 
can't be created in the view again since one of its nodes is missing).  Undo 
will suffice for now.

Comment 13 Ed Willink 2005-06-08 03:11:41 EDT

When a Classifier is deleted, my revised delete code for 98410 goes up to the 
ResourceSet and traverses all resources to find the dangling ends of 
eSuperTypes that derive from the classifier and eReferences that refer (without 
an eOpposite) to the classifier.

Comment 14 Vladimir Harasta 2005-07-22 07:59:44 EDT

Plugin doesn't work in Eclipse 3.1. Compiled from CVS it has 11 warnings, 9 of
them start with:
Discouraged access: ... is not accessible due to restriction on required library ...
When I open some .ediagram file following error appears:
Unable to create this part due to an internal error. Reason for the failure: The
editor class could not be instantiated. This usually indicates that the editor's
class name was mistyped in plugin.xml.

java.lang.ClassNotFoundException:
org.eclipse.gef.examples.ediagram.editor.EDiagramEditor
	at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:403)
	at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
	at
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:78)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at
org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:275)
	at
org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
	at ...

Plugin.xml seems to be OK.

Comment 15 Pratik Shah 2005-07-22 11:15:42 EDT

That sounds like some trivial error in setup on your part.  BTW, you need to 
be using EMF 2.0.1 for now.  See bug 99500.

Comment 16 Ed Willink 2005-07-22 12:41:08 EDT

I get the cannot find error too, but only on one out of two nominally
identical configurations! It is far from obvious. I assumed it was related to
the EMF GEF build correspondence late in the '3.1' release process.
Since EDiagram never got released, I presume it never got the build fix.

(I'm using 3.1 level releases throughout and Java 5 - my only quibbles
are with JDT. GEF and EMF seem fine.)

The discouraged accesses can be fixed by:

Bulk copying
(4 fixes) StringMatcher to .property
(3 fixes) 
ResourceAndContainerGroup,ContainerSelectionGroup,ContainerContentProvider to 
wizards
(2 fixes) Duplicating the 2 GEFMessages. Perhaps these two could be exported by 
GEF.

Randy's conclusion to 100067 fixes the 2 deprecateds.

Since the 3.1 Release Review claims EDiagram is shipped, and since EDiagram
is a very useful example, would it not be better to provide an official
fully built version now, so that we can all install the base version without
having to go through the palava of CVS access and then exporting a plug-in
for self-installation. Perhaps you could keep it in a separate examples
downloadable if you're not happy that it is of as high a quality as the
other examples.

I expect to produce the 0.0 release of my extensible multi-sheet derivation
of EDiagram this week on Eclipse/GMT/UMLX. If you decide that this is the
interim way forward until GMF takes over, it makes even more sense to just do
the absolute minimum to EDiagram to make it 3.1 compatible and put it to bed.

The snap to Geometry feature is fantastic. Is there a trivial variant to
do something for bendpoints too? These are particularly bad since the
enlarged feedback bendpoint icon causes the eventual line to be about one
pixel lower; really hard to manually manhattan route, and there is no diagram
level routing property.

Comment 17 Randy Hudson 2005-07-22 13:34:42 EDT

This bug report has become a dumping ground. We will try to update our build 
process so that the ediagram example gets built and distributed in 3.1.1. 
Opened bug 104845.

Please open specific bugs or feature requests and feel free to post the number 
here in case others want to CC.