[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Move wrapper classes to platform?
|
This is right.
The problem is that we:
a) Won't have a story to contribute Views written with DI to 4.3 SDK
(at least not a full blown one)
b) We don't yet have any story or prototypes to replace editors
Tom
On 19.04.13 15:09, John Arthorne wrote:
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/partsThey
> 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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
