[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gef-dev] Graph Structure Proposal
|
Hi,
we are currently on a trip, so we’ll probably not find time to look at that for a while. Maybe I will be able to answer next week, but I cannot promise that.
Miro
On 28.07.2014, at 19:21, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:
> Zoltan, thanks for having worked this out. Two things came to my mind when taking a deeper look at it:
>
> 1) Shouldn't we now also split it into two bundles, i.e. have an org.eclipse.gef4.kgraph and org.eclipse.gef4.kgraph.impl?
> 2) Why do we haven a MapPropertyHolder as well as an EMapPropertyHolder and related EMapPropertyHolderImpl? Couldn't we simply remove the manually coded MapPropertyHolder and rename the EMapPropertyHolder to MapPropertyHolder, so that MapPropertyHolderImpl would be its proper replacement?
>
> Miro, Christoph-Daniel, what do you think about Zoltan's result? Would that generally serve to fulfill your requirements as well?
>
> As announced, I have spent some time on extending the IAdaptable mechanism (we can now bind the adapters under roles; everything is now available within GEF4 Common) and will take another look at the properties mechanism now. Maybe there's a potential for some synergy. I will keep you updated.
>
> Cheers
> Alexander
>
> Am 25.07.2014 um 11:34 schrieb Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>:
>
>> Hi all,
>>
>> sorry for blaming the EMF code generator, it worked as expected. In this case the issue was with non-generated methods mixed with the EMF-generated code. I missed this, as in our cases we always try to make sure that no hand-coded methods are written inside EMF classes, as in our experience in long term it creates more issues then it solves.
>>
>> I have added some casts required, and now it seems working in my clone: https://github.com/ujhelyiz/kgraph - I see no EMF-specific code in the interfaces. Maybe we will need some further customization to hide the EMF generated package implementation that is still full of EMF references, but if we go with the EMF implementation I deem it still useful.
>>
>> 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.24., at 19:09, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:
>>
>>> Ok, then we have a common understanding on what is to be discussed here and what should rather be left aside. I appreciate this and apologize for not having looked deeply enough into the comments of the bug you referred to.
>>>
>>> Cheers
>>> Alexander
>>>
>>> Am 24.07.2014 um 18:44 schrieb Ed Willink <ed@xxxxxxxxxxxxx>:
>>>
>>>> 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
>>>>>
>>>>> Am 24.07.2014 um 15:00 schrieb Ed Willink <ed@xxxxxxxxxxxxx>:
>>>>>
>>>>>> 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
>>>>>>>
>>>>>>> Am 24.07.2014 um 11:57 schrieb Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>:
>>>>>>>
>>>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
> --
> 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
