[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
Hm - ok I see so the best solution would if we'd have a slot in the
application model which takes an EObject. I doubt we can get something
like this in into the model at this point of the lifecycle, we need
something like
EMap<String,EObject> metaData
Tom
On 03.02.14 19:17, Marco Descher wrote:
> 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
>
