|
Hi
I am sorry but you have misread my comments.
I made it clear that there is "considerable understandable
reluctance to take on board yet more use cases".
You need to make sure that you plan accordingly.
Regards
Ed Willink
On 24/07/2014 14:26, Alexander Nyßen wrote:
Ed,
please do not use our developer mailing list to blame another
project team for not having addressed issues you reported. We
have not even investigated the problem in detail, neither have
we reported it to the EMF team. I do not think any up-front
speculations about their goodwill will bring us forward here.
Cheers
Alexander
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
_______________________________________________
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
|
