[
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 John,
you got me there. :-) I missed one link. I got aware about this blogpost through a discussion on the e4-dev mailing list under the topic "Do we need a book?" [1]
Its a discussion of multiple people and there you find comments about missing DND support (which worked for Tom Schindl), you see a reference to "ported their code from 4.x to 3.x". (also a thing that is discussed their)
No matter whether all facts are true, people from the outside get an impression when they read stuff like that. So I think the focus area is that whoever puts his existing code on top of Eclipse 4.0 should have a smooth experience or well-documented and easy to find breaking-points where re-work(in his/her code) is needed and I dont think we are there yet....
regards
christian
Am 11.01.2012 um 15:48 schrieb John Arthorne:
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
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.
<ATT00001..c>
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
