Re: [e4-dev] Move wrapper classes to platform?

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

If I remember correctly, the original intent
of these wrappers was to provide forwards-compatibility, that is allow
you to write your views/editors so they can run in both 3.x and 4.x while
being able to make use of injection. Why would someone want to use such
a layer in 4.3 and beyond? At this point I thought the path we want to
encourage is to drop the ability to run in 3.x and move parts directly
to the Eclipse 4 API. I'd hate to see people move to these parts and now
have *two* layers of cruft between their parts and the Eclipse 4 framework
(a forwards compatibility layer talking to a backwards compatibility layer
talking to the framework). I see no problem that this stuff continues to
exist for people who need to run on both 3.x and 4.x, but moving it into
the platform somehow sanctions it as a good approach going forward. Is
it?

John



From:      
 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To:      
 
Cc:      
 E4 Project developer
mailing list <e4-dev@xxxxxxxxxxx>
Date:      
 04/18/2013 04:11 PM
Subject:    
   Re: [e4-dev]
Move wrapper classes to platform?
Sent by:    
   e4-dev-bounces@xxxxxxxxxxx

---

Hi,

Lars is right I wrote them ;-) and they are used without problems by the
model editor since their inception.

I think they are fairly done. There was a bug report from Jonas on some
disposing or selection stuff which is not 100% ok. He had a patch i 
revoked because it would have destoryed the active context.

Like other things in e4.tools I'm not actively maintaining them anymore
because my focus has shifted away a bit but I'm always available to 
answer questions and take a glance at patches (like I just did with Dirk
and broke the build the today/yesterday :-)

Their original ident was to make the model editor run in *3.x* (which it
still does?) maybe this support should be removed when moved to eclipse
4 proper?

I'm with Lars, don't make them API but give them more visibility!

BTW: There are many hidden secrets - I came up while doing the tooling
dev - in the e4.tools repo like this (refcount resource management, cool
new i18n support). Unless those get part of Eclipse Platform I plan to
move them to e(fx)clipse and move on there (not everything there is tied
to JavaFX)

Tom

On 18.04.13 21:34, Lars Vogel wrote:
> I definitely would be -1 on adding them as API but I think we may
be
> able to add them to the platform for Kepler as non API and graduate
them
> in 4.4.
>
> You find the relevant classes here:
> http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.compat/src/org/eclipse/e4/tools/compat/parts
They
> are relatively small.
>
> Its hard for me to answer your question about the shape do you think
> they're in as I'm not familiar with the quality standards, maybe Tom,
> the original author, can comment on that? If we don't consider them
API,
> we also have a few cycles left to clean them up, if necessary.
>
> Maybe someone from the platform can have a look at the classes and
tell
> us what we need to do, to graduate these classes.
>
> The nice thing would be that we would have a story for IDE developer
and
> the new programming model.
>
>
> 2013/4/18 Eric Moffatt <emoffatt@xxxxxxxxxx <mailto:emoffatt@xxxxxxxxxx>>
>
>     Lars, I'm +1 with caveats...;-)
>
>     I haven't looked at these classes so I don't know what
shape they're
>     in. My concerns are that this would effectively be adding
new API
>     late in the cycle (past our usual time). If we want
to 'graduate'
>     these classes to become part of the standard eclipse
install they
>     have to be up to 'release; standard (which is much stricter
for IDE
>     components than it is for incubation code). What are
the classes and
>     what shape do you think they're in ?
>
>     I wish this had been brought up earlier, it's obvious
that the
>     Platform is the right place for this code but I'm wondering
whether
>     it may be better to hold off until Kepler releases and
then make
>     sure that this happens *early* (M1) in Luna. During
Luna I hope that
>     we can also look into graduating the Model and CSS editors
but we'll
>     have to see how we can do this since graduating them
will place the
>     code under the stricter 'Platform' standards and I don't
want to
>     inhibit the excellent rate of progress. Perhaps this
is a non-issue
>     since it's brand new code but we'll have to talk it
over at least.
>
>     Eric
>
>
>     Inactive hide details for Lars Vogel ---04/18/2013 09:35:43
AM---Hi,
>     The e4 tools project offers wrapper classes which allow
toLars Vogel
>     ---04/18/2013 09:35:43 AM---Hi, The e4 tools project
offers wrapper
>     classes which allow to wrap POJOs and
>
>
>         From:
>
>                  
   
>     Lars Vogel <lars.vogel@xxxxxxxxx <mailto:lars.vogel@xxxxxxxxx>>
>
>         To:
>
>                  
   
>     E4 Project developer mailing list <e4-dev@xxxxxxxxxxx
>     <mailto:e4-dev@xxxxxxxxxxx>>,
>
>         Date:
>
>                  
   
>     04/18/2013 09:35 AM
>
>         Subject:
>
>                  
   
>
>     [e4-dev] Move wrapper classes to platform?
>
>         Sent by:
>
>                  
   
>     e4-dev-bounces@xxxxxxxxxxx <mailto:e4-dev-bounces@xxxxxxxxxxx>
>
>     ------------------------------------------------------------------------
>
>
>
>     Hi,
>
>     The e4 tools project offers wrapper classes which allow
to wrap
>     POJOs and perform DI on them. The wrapper classes provide
the old
>     API, e.g. one of them extend ViewPart. This allows to
use the new
>     programming model for plug-in development. Tom Schindl
did the the
>     development.
>
>     Is it an option to move the e4 wrapper classes to platform
for
>     Eclipse 4.3? This way people could easily start using
the new
>     programming model via the wrapper classes.
>
>     I think as long as the wrapper classes remain in the
e4 tools
>     project their reach is relatively limited.
>
>     IMHO offering the wrapper classes is a good start for
a migration
>     story for the Eclipse plug-in developers. Also the wrapper
classes
>     from Tom are relatively small.
>
>     Best regards, Lars_______________________________________________
>     e4-dev mailing list
>     e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>     _______________________________________________
>     e4-dev mailing list
>     e4-dev@xxxxxxxxxxx <mailto: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