[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
well he could simply serialize it as XMI and load that ;-) - the other
option is that we introduce an Map<String,EObject> for storage.
This would help anyone who wants to store EObjects but it might lead to
the problem that the model could not be loaded if the .ecore is gone!
Tom
On 03.02.14 19:31, Eric Moffatt wrote:
> Marco, you can store them in the 'persistentData' map, available on any
> model element. It's restricted to Strings but we already have code that
> uses XMLMemento's to format the data....
>
> Eric
>
>
>
> Inactive hide details for Marco Descher ---02/03/2014 01:17:58 PM---Hy
> tom, yes exactly! I did not find a way to store my data Marco Descher
> ---02/03/2014 01:17:58 PM---Hy tom, yes exactly! I did not find a way to
> store my data within the application model itself! I tr
>
>
> From:
>
>
> Marco Descher <marco@xxxxxxxxxx>
>
> To:
>
>
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
>
> Date:
>
>
> 02/03/2014 01:17 PM
>
> Subject:
>
>
> Re: [e4-dev] Horizontal extension possibility for e4 tooling
>
> Sent by:
>
>
> e4-dev-bounces@xxxxxxxxxxx
>
> ------------------------------------------------------------------------
>
>
>
> Hy tom,
>
> yes exactly! I did not find a way to store my data within the
> application model itself! I tried approaches like EMF Facet, but they
> are not suitable to adding attributes to existing EClasses. So I have to
> store the data in a separate model, that refers to elements in the main
> application model!
>
> cheers
>
> An 03. Februar 2014 at 18:11:01, Tom Schindl
> (tom.schindl@xxxxxxxxxxxxxxx) schrieb:
>>
>> I don't get why you need to take part at the model saving. Do you
>> store
>> your information next to the model and not part of it?
>>
>> Tom
>>
>> On 03.02.14 17:48, Marco Descher wrote:
>> > Hy Wim,
>> >
>> > thanks for your feedback! Yes, I think its better, the problem
>> generally boils down to one question:
>> >
>> > I need to be informed at the EP about save() happening for the
>> main resource, so that I can store
>> > mine. The cheapest solution would surely be a saveHook EP so
>> anyone that might have this request is
>> > informed of this save event.
>> >
>> > I could as well just leave this problem out for the moment being
>> and care or the save on my site (by
>> > adding a save button to my contributed tabs for example).
>> >
>> > I’m really puzzled at the moment, but I don’t have a problem if
>> we hold on!
>> >
>> > atb,
>> > marco
>> >
>> > An 03. Februar 2014 at 17:41:52, Wim Jongman (wim.jongman@xxxxxxxxx)
>> schrieb:
>> >>
>> >> It is hard to tell Marco. I have to make some time to really get
>> to
>> >> know
>> >> your solution. Do you think we should hold on to accepting your
>> >> patch until
>> >> this is sorted out?
>> >>
>> >> Cheers,
>> >>
>> >> Wim
>> >>
>> >>
>> >>
>> >> On Mon, Feb 3, 2014 at 4:10 PM, Marco Descher
>> >> wrote:
>> >>
>> >>> https://git.eclipse.org/r/#/c/18813/
>> >>>
>> >>> I found a "minimally invasive" solution, which I do not really
>> >> like, so I
>> >>> hope for a better proposal:
>> >>>
>> >>> I extended my classes in general by giving them dependency
>> injection,
>> >> and
>> >>> if one extends the MApplication.class
>> >>> and has a method with @Persist in it, it gets called by the "parent"
>> >> so
>> >>> one can handle oneselves persistence.
>> >>>
>> >>> ==== ModelEditor:line 1366
>> >>> @Persist
>> >>> public void doSave(@Optional IProgressMonitor monitor)
>> >> {
>> >>>
>> >>> try {
>> >>> setSaving(true);
>> >>> if (modelProvider.isSaveable()) {
>> >>> modelProvider.save();
>> >>>
>> >>> List aeec =
>> >>> getTabContributionsForClass(MApplication.class);
>> >>> for (AbstractElementEditorContribution aeecChild :
>> >>> aeec) {
>> >>> try {
>> >>> ContextInjectionFactory.invoke(aeecChild,
>> >>> Persist.class, context);
>> >>> } catch (InjectionException e) {
>> >>> // ignore
>> >>> }
>> >>> }
>> >>>
>> >>> }
>> >>> } finally {
>> >>> setSaving(false);
>> >>> }
>> >>> }
>> >>>
>> >>> --
>> >>> Marco Descher
>> >>> Sent with Airmail
>> >>>
>> >>> An 02. Februar 2014 at 22:49:47, Marco Descher (marco@xxxxxxxxxx)
>> >> schrieb:
>> >>>>
>> >>>> The extension itself works quite good for me you may have
>> a look
>> >>>> at it in https://git.eclipse.org/r/#/c/18813/
>> >>>>
>> >>>> I am having a "problem" however, where I would like to see
>> your
>> >>>> comment:
>> >>>>
>> >>>> I use the extension point to load a second model, which connects
>> >>>> to the first model. Now I want to save the second
>> >>>> model when I do the save operation on the first model. The
>> respective
>> >>>> call is embedded in @Persist ModelEditor#doSave.
>> >>>> Now I cant seem to use DI in my contribution tabs, so I guess
>> I
>> >> would
>> >>>> have to pass the save method calling to the
>> >>>> extension point. As one may register several editorTab
>> contributions
>> >>>> (each e.g. for a specific element) I plan to extend another
>> >>>> class in the editorTab EP where this is passed to!
>> >>>>
>> >>>> Do you see a better solution for this I miss out?
>> >>>>
>> >>>> thanks,
>> >>>> marco
>> >>>>
>> >>>> An 17. Jänner 2014 at 16:07:23, Marco Descher (marco@xxxxxxxxxx)
>> >>>> schrieb:
>> >>>>>
>> >>>>> Hy Wim,
>> >>>>>
>> >>>>> ok, I agree. But I want to find a way to non-invasively extend
>> >>>> the
>> >>>>> existing application model first, as I think that then
>> the
>> >> extension
>> >>>>> point really makes sense! Currently I found EMF Facets
>> which
>> >>>>> could be a good starting point. And if it proves well, I would
>> >>>> create
>> >>>>> it the way, that facets are supported. Because this way
>> you
>> >> could
>> >>>>> provide your own facet with your own additional attributes
>> >>>> etc.
>> >>>>> and integrate them fully into the eclipse tooling.
>> >>>>>
>> >>>>> I will come up with the respective gerrit entries in due
>> time
>> >>>> :)
>> >>>>>
>> >>>>> thanks,
>> >>>>> marco
>> >>>>>
>> >>>>> --
>> >>>>> Marco Descher
>> >>>>> Sent with Airmail
>> >>>>>
>> >>>>> An 17. Jänner 2014 at 16:02:58, Wim Jongman
> (wim.jongman@xxxxxxxxx)
>> >>>>> schrieb:
>> >>>>>>
>> >>>>>> Hi Marco,
>> >>>>>>
>> >>>>>> Since there is no documentation attached to the existing
>> >> extension
>> >>>>>> point I
>> >>>>>> figured we can just use it the way we want.
>> >>>>>>
>> >>>>>> Take for example the ui.views extension point. It can
>> be
>> >> used
>> >>>>>> to add views
>> >>>>>> but also to add view categories. Two related but different
>> >>>> concepts.
>> >>>>>> Since
>> >>>>>> your extension works with the model editor it makes sense
>> >> to
>> >>>>> move
>> >>>>>> it to the
>> >>>>>> existing extension point.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>>
>> >>>>>> Wim
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, Jan 17, 2014 at 1:17 PM, Marco Descher
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Hy Wim,
>> >>>>>>>
>> >>>>>>> as I found out during the documentation, the current
>> extension
>> >>>>>> point is
>> >>>>>>> not extending the tooling in this way. It is mainly focused
>> >>>>> on
>> >>>>>> adding
>> >>>>>>> editors for new model elements instead of augmenting
>> the
>> >>>> editor
>> >>>>>>> capabilities for existing elements (there are Exceptions
>> >>>>>> but I don't think
>> >>>>>>> they go the right way). I currently forked the tooling
>> on
>> >> github
>> >>>>>> and work
>> >>>>>>> with my own build (https://github.com/ecrit/e4.tools).
>> >>>>>> During this I
>> >>>>>>> might uncover some problems and do a complete refactoring.
>> >>>>>> So I think I
>> >>>>>>> just stick it this way at the moment, and will come up with
>> >> another
>> >>>>>>> integration approach in a few months!
>> >>>>>>>
>> >>>>>>> I also don't think that it makes much sense to augment
>> the
>> >> editing
>> >>>>>>> capabilites of the existing model elements, as most
>> certainly
>> >>>>>> you have to
>> >>>>>>> add new attributes to these, or did I miss a way to contribute
>> >>>>>> to existing
>> >>>>>>> elements, without having to create new EMF classes extending
>> >>>>>> those?
>> >>>>>>>
>> >>>>>>> thanks,
>> >>>>>>> marco
>> >>>>>>>
>> >>>>>>> An 07. Jänner 2014 at 10:46:09, Marco Descher (marco@xxxxxxxxxx)
>> >>>>>> schrieb:
>> >>>>>>>>
>> >>>>>>>> Hy there,
>> >>>>>>>>
>> >>>>>>>> that would make sense, I guess. Although I think that
>> I
>> >> would
>> >>>>>> first
>> >>>>>>>> have to document the existing extension point
>> >>>>>>>> code some more to be sure about it. I'll open a bug for
>> adding
>> >>>>>> some
>> >>>>>>>> documentation and throw it on gerrit then.
>> >>>>>>>>
>> >>>>>>>> cheers,
>> >>>>>>>> marco
>> >>>>>>>>
>> >>>>>>>> An 06. Jänner 2014 at 18:23:47, Wim Jongman (
>> >>> wim.jongman@xxxxxxxxx)
>> >>>>>>>> schrieb:
>> >>>>>>>>>
>> >>>>>>>>> Marco how would you feel moving your extension to the
>> >> already
>> >>>>>>>>> existing
>> >>>>>>>>> extension point.
>> >>>>>>>>>
>> >>>>>>>>>> point="org.eclipse.e4.tools.emf.ui.editors">
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Tom would this be the right point to extend the model
>> editor?
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Nov 26, 2013 at 11:12 AM, Sopot Çela
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Thanks Marco, I'll take a look and get back to you.
>> >>>>>>>>>>
>> >>>>>>>>>> Sopot
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Mon, Nov 25, 2013 at 12:57 PM, Marco Descher
>> >>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hy Sopot,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I created a short demo, and pushed it to gerrit in
>> >>>>>>>>>>> https://git.eclipse.org/r/#/c/18813/ . A sample
>> >>>> plug-in
>> >>>>>>>>> consuming the
>> >>>>>>>>>>> respective extension point is available on
>> >>>>>>>>>>>
>> >>>>>>>
>> >>>
> https://github.com/col-panic/generic-stuff/commit/cb4cc272ab4d0da33cd7462519c0ed51231fc029
>
>> >>>>>>> .
>> >>>>>>>>>>>
>> >>>>>>>>>>> It is intentionally kept simple, and hacked!! So
>> for
>> >>>> an
>> >>>>>> element
>> >>>>>>>>> of type
>> >>>>>>>>>>> MPart you get an additional CTabItem where currently
>> >>>>> simply
>> >>>>>>>>> the ID
>> >>>>>>>>>>> attribute is mirrored.
>> >>>>>>>>>>>
>> >>>>>>>>>>> It should show the basic concept and point out the
>> required
>> >>>>>>>>> refactorings?!
>> >>>>>>>>>>>
>> >>>>>>>>>>> cheers,
>> >>>>>>>>>>> marco
>> >>>>>>>>>>>
>> >>>>>>>>>>> Am 20.11.2013 um 09:59 schrieb Sopot Çela :
>> >>>>>>>>>>>
>> >>>>>>>>>>> Marco would you be able to make a proof of concept
>> for
>> >> one
>> >>>>>> element
>> >>>>>>>>> (say
>> >>>>>>>>>>> MPart) and throw it on gerrit? I like the idea in principle
>> >>>>>>>> but
>> >>>>>>>>> it would be
>> >>>>>>>>>>> great to have something to see and extend and get
>> the
>> >> feel
>> >>>>>> of
>> >>>>>>>>> it from my
>> >>>>>>>>>>> keyboard.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Sopot
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Wed, Nov 20, 2013 at 8:08 AM, Lars Vogel
>> >>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think we should avoid a dependency to ECP.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> At some point the tooling should migrate to PDE
>> or
>> >> platform
>> >>>>>>>>> and these
>> >>>>>>>>>>>> tools can AFAIK not depend on a higher level in Eclipse.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Best regards, Lars
>> >>>>>>>>>>>> Am 19.11.2013 21:25 schrieb "Jonas Helming" <
>> >>>>>>>>>>>> jonas.helming@xxxxxxxxxxxxxx>:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>> I totally like the idea. However, it reminds me
>> to
>> >> an
>> >>>>> idea
>> >>>>>>>>> I have since
>> >>>>>>>>>>>>> a long time, which is related to your question.
>> >>>>>>>>>>>>> When Tom implemented the first version of the
>> e4
>> >> tools
>> >>>>>> editor,
>> >>>>>>>>> he
>> >>>>>>>>>>>>> actually contacted me if the EMF Client Platform
>> >> could
>> >>>>>>>> be
>> >>>>>>>>> used for this.
>> >>>>>>>>>>>>> Back than, ECP had some restrictions:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 1. The form-based editor was not really usable
>> stand-alone
>> >>>>>>>>> or embeddable
>> >>>>>>>>>>>>> 2. We did not really support to customize the layout
>> >>>>>>>>>>>>> 3. We did not support a Master Detail view within
>> >> a form
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> In the mean time, these restrictions are not valid
>> >>>> anymore:
>> >>>>>>>>>>>>> 1. The editor component can be used stand-alone
>> >> and
>> >>>>> embedded
>> >>>>>>>>> everywere,
>> >>>>>>>>>>>>> it is a sub component called EMF Forms
>> >>>>>>>>>>>>> 2. The layout of the form-based UI can itself be
>> described
>> >>>>>>>>> with an EMF
>> >>>>>>>>>>>>> model (see
>> >>>>>>>>>>>>>
>> >>>>>>>
>> >>>
> http://eclipsesource.com/blogs/tutorials/emf-client-platform-how-to-customize-the-editor-layout/
>
>> >>>>>>>>>>>>> )
>> >>>>>>>>>>>>> 3. We currently develop a master detail view,
>> which
>> >>>>> is
>> >>>>>> almost
>> >>>>>>>>> finished
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Major advantages of this would be IMHO:
>> >>>>>>>>>>>>> 1. The code base of the e4 editor would get drastically
>> >>>>>> smaller
>> >>>>>>>>> and
>> >>>>>>>>>>>>> would only focus on e4 model specific aspects
>> >>>>>>>>>>>>> 2. Custom Applications elements can be edited
>> without
>> >>>>>>>> any
>> >>>>>>>>> adaption, as
>> >>>>>>>>>>>>> ECP still support reflective UIs
>> >>>>>>>>>>>>> 3. The layout of the editor can be easily customized
>> >>>>> by
>> >>>>>> users
>> >>>>>>>>> using a
>> >>>>>>>>>>>>> view model
>> >>>>>>>>>>>>> 4. New concepts such as the one you describe can
>> be
>> >> asily
>> >>>>>>>> added
>> >>>>>>>>>>>>> 5. The e4 editor would benefit from ECP features,
>> >> e.g.
>> >>>>>> validation
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> The main disadvantage is of course that this would
>> >>>> require
>> >>>>>>>>> initial
>> >>>>>>>>>>>>> effort. Your suggested solution is of course
>> much
>> >>>> easier
>> >>>>>>>>> to implement for
>> >>>>>>>>>>>>> now. Additionally e4 Tools would get a depenency
>> >> to
>> >>>>> ECP.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I just wanted to share this thought to get peoples
>> >>> opinions.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Cheers
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Jonas
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Am 19.11.2013 13:05, schrieb Marco Descher:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Hy List,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> WHAT
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I would like to add horizontal extension possibility
>> >>>>>> to
>> >>>>>>>>> the e4
>> >>>>>>>>>>>>> tooling. That is, there already is the possibility
>> >>>>> to
>> >>>>>> add
>> >>>>>>>>> new elements to
>> >>>>>>>>>>>>> the application model, and provide ones own editors
>> >>>>>>>>>>>>> for the e4 tooling. I would like to extend the tooling
>> >>>>>> for
>> >>>>>>>>> already
>> >>>>>>>>>>>>> available elements by adding an extension point
>> >> to
>> >>>>> the
>> >>>>>>>> tooling
>> >>>>>>>>> itself.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> WHY
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I want to enrich already available elements with
>> >>> additional
>> >>>>>>>>>>>>> information. This could for example be used to
>> add
>> >>>> documentation
>> >>>>>>>>>>>>> information to all elements of the application
>> >> model,
>> >>>>>>>>>>>>> or would allow me to e.g. create an additional
>> tab,
>> >>>> valid
>> >>>>>>>>> only if I use
>> >>>>>>>>>>>>> the SWT renderer, allowing me to do deeper inspection
>> >>>>>> of
>> >>>>>>>>> the model.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> HOW
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I plan to create an extension point allowing to
>> contribute
>> >>>>>>>>> tabs to
>> >>>>>>>>>>>>> given elements, as can be seen in the following
>> image.
>> >>>>>> The
>> >>>>>>>>> extension point
>> >>>>>>>>>>>>> will have to define for
>> >>>>>>>>>>>>> what model elements the contributed tab is valid,
>> >>>> and
>> >>>>>> on
>> >>>>>>>>> call of the
>> >>>>>>>>>>>>> editor the full model will be passed.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Can you please give me any feedback, on what you
>> think
>> >>>>>> about
>> >>>>>>>>> this,
>> >>>>>>>>>>>>> who would back/mentor this implementation,
>> and
>> >> what
>> >>>>>> he/she
>> >>>>>>>>> would do
>> >>>>>>>>>>>>> different?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>>> marco
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>> e4-dev mailing liste4-dev@eclipse.orghttps://
>> >>>>>>> dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>> e4-dev mailing list
>> >>>>>>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>> e4-dev mailing list
>> >>>>>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> e4-dev mailing list
>> >>>>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> e4-dev mailing list
>> >>>>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> e4-dev mailing list
>> >>>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> e4-dev mailing list
>> >>>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> e4-dev mailing list
>> >>>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> e4-dev mailing list
>> >>>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> e4-dev mailing list
>> >>>>>> e4-dev@xxxxxxxxxxx
>> >>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> e4-dev mailing list
>> >>>>> e4-dev@xxxxxxxxxxx
>> >>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> e4-dev mailing list
>> >>>> e4-dev@xxxxxxxxxxx
>> >>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> e4-dev mailing list
>> >>> e4-dev@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>>
>> >> _______________________________________________
>> >> e4-dev mailing list
>> >> e4-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >>
>> >
>> > _______________________________________________
>> > e4-dev mailing list
>> > e4-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
