Hi
Certainly raise a bug withy the repro and ideally the fix, but you
may find that as I did with, for example,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=414352
that the streamlined efficient code use case is not well
supported.
Regards
Ed Willink
On 24/07/2014 11:57, Alexander Nyßen wrote:
I agree. We should report such kind of errors, before taking any
other actions.
Cheers
Alexander
Hi,
thanks for the information. Still, I believe, it is
important to try it, as it seems like a clear bug to me,
as it resulted in a compile error; and it is the best if
we don't have to maintain our own generators.
Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
On 2014.07.23., at 18:33, Ed Willink
<ed@xxxxxxxxxxxxx> wrote:
Hi
"and try to push it back to upstream rather than do our
own version"
Expect this to fail. EMF is complex with many use cases.
There is therefore considerable understandable
reluctance to take on board yet more use cases.
Regards
Ed Willink
On 23/07/2014 15:35, Ujhelyi Zoltán wrote:
Hi Ed,
thanks for your comments. I have already used the
Suppress-EMF-Types genmodel option for the code I have
created.
About custom templates and internal EMF hacking, I was
more prepared to find out where it goes wrong with the
original templates, and try to push it back to
upstream rather than do our own version. Our basic
goal was to see whether we can use both an
EMF-dependent and an EMF-independent API, to have the
best of two worlds. However, I guess it is still
important to evaluate how much do we want the two
APIs; and if we decide, it is, than it also makes
sense to generate our own from the original EMF model.
Regards,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
On 2014.07.23., at 16:29, Ed Willink
<ed@xxxxxxxxxxxxx> wrote:
Hi
The Suppress-EMF-Types genmodel option ensures you
use List rather than EList.
You might manage to use some variant of unsettable
to make
getCollection() internal so that you just have a
getSafeCollection() that wrap an immutable list
around it.
Be very very wary of introducing improved generator
templates; you will find bit rot sets in very very
rapidly; chasing EMF changes is very tedious.
If you want a simple API, it is really easy to write
a custom Ecore to MyJava M2T with Acceleo or Xtend,
so once you're happy with your EMF-based development
do your own M2T so that you are independent of EMF
evolution.
Regards
Ed Willink
On 23/07/2014 14:43, Ujhelyi Zoltán wrote:
Hi,
I have looked at the EMF model, and played a bit
with the code generation settings for a start. My
results are in my fork of the Github repository:
https://github.com/ujhelyiz/kgraph
Results/problems:
1. The interfaces do not refer to EMF stuff, e.g.
there is no base interface, and simple ELists are
used instead of Lists, etc.
2. The Map implementation is handled differently,
so in the implementation class there is some
related compile error related the EMF class is
used incorrectly. I am not sure how large effort
is needed to update the EMF generator to handle
this case correctly, but it is definitely doable.
3. If we want to have an EMF-independent
implementation, there is a single API
functionality that is hard to implement using
EMF-style: multi-valued references are handled by
a single getter that returns an _editable_
collection. These editable collections are
problematic, as it is expected that the internal
model stays consistent with these editing steps,
so we will most likely need custom collections to
handle this case.
As both steps 2 and 3 require significant amount
of work, at first I would like to discuss
whether/how would we like to use EMF, and in which
way. Some arguments and counterarguments for using
EMF:
+ EMF maintains several internal consistency, e.g.
supports bi-directional traversal; additionally
extra validation is possible if needed.
+ EMF provides a notification mechanism that will
be required by our tools as well (e.g. updating
the visualization on model changes).
+ Serialization/export support - either built-in
(via XMI), or custom (e.g. using code generators).
- EMF dependency. Depending on who we ask, this
might be tough (larger application size,
dependency management) or minor (e.g. Eclipse 4
Platform already depends on it, and works outside
Eclipse as well).
Cheers
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
On 2014.07.22., at 9:58, Alexander Nyßen
<alexander.nyssen@xxxxxxxxx> wrote:
Hi Miro,
I could take a first short glance and some
(conceptual) questions already came to my mind,
while I unfortunately did not have the time to
look into all details yet:
- What exactly was the motivation of factoring
our EdgeLayout into own interface? Does it make
sense to haven an Edge without the properties
contained therein?
- What was the motivation of doing the same for
ShapeLayout? It seems all GraphElements extend
also this interface. Why is there then no
"Shape" abstraction but only a ShapeLayout?
- Why exactly do we need the PropertyMapping? It
seems transient properties are already handled
by a map. Why not use the same mechanism here?
What is the notion of "persisting" them?
@Zoltán: Could you take a look into how we could
realize the separation between EMF-unrelated
interfaces and EMF-based implementation?
Cheers
Alexander
Am 17.07.2014 um 14:42 schrieb Alexander Nyßen
<Alexander.Nyssen@xxxxxxxxx>:
Thanks Miro. I will
probably have to for a detailed look tomorrow
to give a first feedback.
I would like to do the discussion here or in a
related bug (but not outside of the Eclipse
infrastructure), so our community can
participate.
Cheers
Alexander
Am 16.07.2014 um 13:21 schrieb Miro Spönemann
<msp@xxxxxxxxxxxxxxxxxxxxxx>:
Hi all,
I created an Ecore-based graph structure
proposal in a GitHub repository:
http://github.com/franchi82/kgraph
Feel free to experiment with it. I suggest
that discussion on this proposal should be
continued using GitHub issues.
Regards
Miro
On 09.07.2014, at 23:10, Alexander Nyßen
<alexander.nyssen@xxxxxxxxx> wrote:
Regarding
the question whether to use EMF or
not, we decided that we
(read: the KIELER project) need
EMF in any case. We have two
options:
* specify the data structure
directly in Ecore, or
* create interfaces and an
EMF-independent implementation in
one plugin
and an Ecore-based implementation
in another plugin.
Even if EMF is used, it is
possible to use the data structure
in
Eclipse-independent applications
by shipping the plugins
org.eclipse.emf.common and
org.eclipse.emf.ecore with it.
This gives an
overhead of about 1.6 MB.
I do not object to using EMF and I
think that the overhead is something
that we could well live with.
Actually the approach you describe
would facilitate the split of GEF4
Graph into interfaces and
implementation, as I proposed
earlier. I think from our viewpoint,
the following would be desirable:
1) the generated interfaces should
not make use of the EMF collection
classes (i.e. use a plain List
instead of an EList) and (if
possible) should not extend EObject,
so we could put them into a bundle
without any EMF dependencies (I
think this can be achieved by
certain EMF genmodel options).
2) the implementation classes could
be put into a separate bundle that
depends on EMF. I do not think we
would have to provide a
non-EMF-based implementation in
addition, at least I do not see a
direct use case for this yet.
This way, the use case of writing
adapters between GEF4 Graph
interfaces and a custom model would
remain pretty much lightweight (no
EMF contracts to follow), while a
transformation scenario would also
be best supported (here, EMF seems
to be advantageous).
It is possible to remove all EMF
classes from the interface. The only
thing required is having some javadoc
tags defined for the interface, after
that EMF can generate everything
required. I have first-hand experience
with this - if we can follow the
(naming) conventions of EMF, it works
really well. The most problematic
point I see is providing a modifiable
list for multivalued attributes - this
requires specific list implementations
that can send change notifications (at
least if we want to make the graph
model dynamic).
Would it be feasible that I send a
proposal consisting of an Ecore model
file, and you generate EMF-free
interfaces + EMF-bound implementation
out of it?
That would probably be useful (1) to
concretize our discussions about the
actual changes that would have to be
applied to GEF4 Graph to match your
requirements and (2) to confirm whether
the intended approach of separating GEF4
Graph into a set of EMF-indenpendent
interfaces and related EMF-based
implementation is feasible. As such, I
would welcome this procedure.
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang
Neuhaus, Dr. Georg Pietrek, Jens Trompeter,
Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.),
Stephan Grollmann, Michael Neuhaus
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang
Neuhaus, Dr. Georg Pietrek, Jens Trompeter,
Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan
Grollmann, Michael Neuhaus
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7903 -
Release Date: 07/22/14
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7903 -
Release Date: 07/22/14
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr.
Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.),
Stephan Grollmann, Michael Neuhaus
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7907 - Release Date: 07/23/14
|