Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Proposal to discuss "e4" compatibility on Thursday

Hi Christian,

This sounds like a fine discussion topic for tomorrow. Just to be sure we have all the information, can you double-check that the blog link you give is correct? I can't see any reference there to porting an application from e4 to 3.x, or problems with DnD in e4. I see the "not mature enough" comment, but that might have been from a year ago when they were building their alpha product. We can talk about the details tomorrow but wanted to make sure we have all the context you are referring to.

John




"Campo, Christian" <Christian.Campo@xxxxxxxxxxxx>
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

01/10/2012 10:17 AM

Please respond to
"eclipse.org-architecture-council"        <eclipse.org-architecture-council@xxxxxxxxxxx>

To
"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
cc
Subject
[eclipse.org-architecture-council] Proposal to discuss "e4"        compatibility on Thursday





Hello architects,


I am proposing to talk about "e4" and its "compatibility" with 3.x on the next meeting that I believe is Thursday this week.

Compatibility when porting from "e4" to 3.x came up on multiple levels on my personal radar:

1. There is a blogpost on planet eclipse that some may have read [1] where they talk about an RCP application that was ported back from E4 to Eclipse 3.x because of some issues with e4. (missing DND support and one comment about "being not mature enough")

2. Eclipse Riena has a strong investment and vision in making RCP apps look more enduser friendly.You can see some example screenshots here [2] This is/was based on the presentation API of RCP 3.x. While most of the 3.x. is still around at least in the compat layer, the presentation API is gone.

Things that surprises me are:

- Riena still worked in "compat" mode on top of e4 1.0RC1. (which also contained the modelled workbench)

- The presentation API i.e. the classes are still in .jar archives, they just dont function anymore (no compile errors) which I personnally find a little odd.

- Yet it is unclear and to my knowledge undocumented where the boundaries of this "presentation api" are....
   So if you look at Bug 361133 [3] you see that Tom Schindl named in comment 5 this (the method createWindowShell) as part of this presentation API or theming API. It wasnt clear to me before that this is one belongs to the "presentation API" and obviously it was also not clear to Eric Moffat who is also in the comment thread.

Just to be clear and I understand that API sometimes has to be abandoned to create something better. (Riena BTW does that quite frequently that we deprecate and then delete API and replace it with something better). However the lack of documentation and the fact that this method still exists (is not even deprecated) and yet is no longer called, is a frustrating thing when debugging on a not longer RCP app.

My view is however that as much as it surprises me (that a callback method that exists for a long long time is still around, yet no longer part of the lifecycle) that this might even shock people further down the product line.....

(So quite understandable, in my opinion, that Paul Webster marked this bug as Major this morning)

As a consequence I opened Bug 368147 [4]  which requests that API that is longer functioning should be removed (as in DELETED) in eclipse 4.x so that consumers can easily see which parts of their application needs re-work.

3. In the light of this discovery I digged deeper why we hadnt come accross this earlier and as mentioned before we tested Riena on e4 1.0RC1 which is from around June 2010. E4 back then was still a lot different, yet it also had a modelled workbench and the compat layer supported the presentation API. Riena comes up without any problem whatsoever. So it seems that having a presentation API is not a total contradiction to having a modelled workbench. So running a 3.x RCP on top of e4 1.0 was a lot smoother.

4. So we in Riena need to continue on the e4 topic and we are still not there where Riena works again on top of Eclipse 4.x. Its my understanding that we are required to drop out of the release train if we cant get this problem fixed by June.

So again "e4" is great (really !!!), just the transformation to "e4" is not as seemingless as we hoped. To my knowledge we are probably the only project in the release train that has this very tight bindings and dependencies on the presentation API. But there might be others in the consuming community.

I know that such a discussion can become quickly very technical and thats no really what I am aiming at. I am looking in the direction of who else will have problems consuming Juno who was working fine with Indigo and only consider Riena as a sample of problems you might be seeing.

So maybe that is a good topic for discussion on thursday. What do you think ?

regards
christian campo



[1] http://milesparker.blogspot.com/2012/01/butterflyzer-beta.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+MetaBeta+%28meta+beta%29
[2] http://www.google.com/search?q=riena+screenshot&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=9j8MT6P7K8nNsgbpwfi2BA&sa=X&oi=mode_link&ct=mode&cd=2&ved=0CA0Q_AUoAQ&biw=1125&bih=986
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=361133
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=368147

-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main

fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web:
www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


Back to the top