| Re: [e4-dev] Move wrapper classes to platform? |
The take from the Platform team is the platform should be responsible for correctly hosting e4 contributions within the IDE so there should be no need for the average e4 developer to even know about the wrapper classes. The approach is to refactor a number of the existing Extension Points to allow direct contributions whose implementations are e4-based. The platform would then be responsible for hosting these 'seamlessly' into the IDE by providing whatever wrapping is needed so that folks using the old API's can at least be aware that the e4 view exists (for example it has to show up in 'getViewReferences'...).
If we provide the support above is there another reason to expose the wrapper classes ?
Note that whatever the answer is that it's far too late to consider getting these into Kepler but there's no reason for not continuing to use them if it makes sense for you in the e4 environment.
I do understand and appreciate that this still leaves us with no 'official' mechanism to manage e4 contributions. Up until now the focus has had to be on backwards compatibility and we *know* that starting with Luna we have to start focusing on blurring the e4 / IDE boundaries in both directions.
At least Luna should be chalk full of New and Noteworthy items...;-),
Eric
Jonas Helming ---05/06/2013 06:31:49 AM---Hi, has there beend any conclusion on this topic?
From:
Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>
To:
e4-dev@xxxxxxxxxxx,
Date:
05/06/2013 06:31 AM
Subject:
Re: [e4-dev] Move wrapper classes to platform?
Sent by:
e4-dev-bounces@xxxxxxxxxxx
Hi,
has there beend any conclusion on this topic?
Regards
Jonas
Am 24.04.2013 21:34, schrieb Joseph D Carroll Jr:Why not adopt a strategy where all org.eclipse.ui.* EP's are wrapped in an injectable part?
_______________________________________________
In August I proposed that we modify the class template / byte code to include the annotations (probably because that's when I first learned you could do something like that). If that is still a viable option I'm not sure it would be worth the amount of work.
What I was really trying to get at with that proposal is using the existing API to treat all workbench contributions (o.e.u.* EP's) as E4 parts. Then there isn't an issue of mixing 3.x parts with 4.x parts because the workbench sees them all as 4.x parts. At the same point, if a 3.x part requests a separate workbench part (view / perspective / etc. ), it is relatively straight forward to provide it with a 3.x part. Even if the requested part is defined within a fragment, we can "mach-up" a bridge for the 4.x part to make it appear as a 3.x part.
In my mind this provides a *true* compatibility layer. The migration story becomes simple at that point: migrate what you want, when you want. To migrate a view all you would have to do is break the inheritance from ViewPart (which wouldn't even be necessary) and add a couple of annotations. Maybe we create an optional @E4Part annotation. This way when we look to wrap the contributed part in an injectable E4 part, if any of @E4Part, @PostConstruct, @Focus, etc... are present the contribution isn't wrapped and treated as a raw E4 part. Then you wouldn't have to change *any* code except for adding a couple of annotations. This would also allow you to have 3.x & 4.x parts contributed from the same bundle.
I have been working on something that demo's this functionality, but I recently started with a new company and haven't had much time. Hopefully in the next couple of weeks I will have something I can share.
JD
On Tue, Apr 23, 2013 at 10:26 AM, Jonas Helming <jonas.helming@xxxxxxxxxxxxxx> wrote:Hi,
I have fixed a few minor issues on the wrapper classes in the last month. I use them in a couple of projects. The typical users are bound to 3.x because they use some components not available for e 4. I also think they fit into the platform. However there is at least one thing to do, before I would move them. Currently some of the services used in the wrappers are in the tools.services plugin, some are in the compat plugin. The compat plugin needs to provide wrapper interfaces for services which are different in 3x and e4.
I already discussed that with Tom. IMHO, A good solution would be: move all service interfaces to one plugin: compat.services. Create two implementations: 3x and e4 in separate Plugins.
Additionally the CSS stuff should be moved into its own plugin, which makes the compat plugin RAP compatible.
I have even started to make this refactoring. After that the compat plugin would also be independent of any other tools plugin.
I agree with Lars, it should not be API in Kepler. I would be willing to apply the changes described above, but I am currently not in office. When is the latest date to move the plugins for Kepler?
Regards
Jonas
Von meinem iPhone gesendet
Am 23.04.2013 um 20:42 schrieb Eric Moffatt <emoffatt@xxxxxxxxxx>:
I'm with John on tthis one...when running on top of a 4.x IDE there should be no need for the part developer to even know about the legacy implementations, the IDE itself should manage this since only it really knows what the requirements are. As far as JD;s comments go this came up at the BOF at EclipseCon this year with differing viewpoints being expressed. For me I don't see extensions going away in 4.x; the tooling is all there (Schemas, Docs, templates...) and the mechanism is both widely used and understood by the Eclipse community. For folks that are coming from an eclipse background (i.e. developed for eclipse before e4) this would certainly be the expected route for them to use (so we can get them hooked on e4...;-).
Using the existing EP's may also provide e4 a quicker path to having a fully functional 'editor' specification. The question remains whether the e4 community should also be able to consume at least some of the extension points directly (perhaps modified, see below). For me the answer is 'yes', as part of moving things away from the IDE and into e4 is makes sense to move the IDE code that scrapes the org.eclipse.ui.views registry and creates the MPartDescriptors out to some place in e4. Deciding exactly which EP's to consume should be done on a case by case basis (I..e do we want to expose the current Perspective[Extension] EP or do we want to have a simper one that rather than using IPerspectiveFactory just passes in an MPerspective to be filled in using model code?).
As the fragment story gets fleshed out some folks (particularly people that haven't had any eclipse experience) may want to go that route because the learning curve is shorter than learning how to use all the various existing extension points. How many go this route will depend on how easy we can make it and how god the docs are.
Given that we wan to use the existing 'views' extension point let's see what we need. The first part of the task is indeed fairly easy; check whether the defined 'class' extends ViewPart and if not then just create it through injection. There are a few things that complicate this though:
- Various IDE API methods / events expose legacy implementation details such as IViewPart, ViewReferences... (same for editors). We'll need to create proxies to pass to satisfy these constraints. Since these are IDE concepts the IDE should manage them.
- The schemas define that the 'class' extend ViewPart and this gets used by PDE's tooling to pre-populate the 'New Class' dialog when it's used (as well as to filter the 'Find' results). Obviously we'll have to do something here to loosen up these constraints. This same pattern will also be needed for some of the other extensions (Editors, Handlers...).
Hmmm, somewhat longer than I expected...;-). The upshot is that for folks contributing to the IDE using modified versions of the existing EP's is the right way to go. While it's less clear that e4 RCP apps need to use EP's they're certainly useful and IMO would be of value even to EAP developers.
Eric
<graycol.gif>Wim Jongman ---04/23/2013 05:59:04 AM---Yes, I think it is a good idea from Patrick and John to automatically convert the view on the fly. I
<ecblank.gif> From:
<ecblank.gif>
Wim Jongman <wim.jongman@xxxxxxxxx><ecblank.gif> To:
<ecblank.gif>
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,<ecblank.gif> Date:
<ecblank.gif>
04/23/2013 05:59 AM<ecblank.gif> Subject:
<ecblank.gif>
Re: [e4-dev] Move wrapper classes to platform?<ecblank.gif> Sent by:
<ecblank.gif>
e4-dev-bounces@xxxxxxxxxxx
Yes, I think it is a good idea from Patrick and John to automatically convert the view on the fly. It is a trivial thing (in my mind at least) to check if this view implements iviewpart and if not, create a wrapper for it so that it can be a first class citizen in the "mixed mode / IDE" story.
I filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=406307
Lets take the discussion overthere
Regards,
Wim
On Mon, Apr 22, 2013 at 10:45 PM, Joseph D Carroll Jr <jdsalingerjr@xxxxxxxxx> wrote:Where do people see the place of the plugin.xml in the long-run (versus a fragment.e4xmi)? Certainly the plugin.xml will be used for defining custom extension-points as it is now. But will any of the org.eclipse.ui.* extension points survive, or is the sentiment to [eventually] deprecate all of them in favor of fragments?
_______________________________________________
If the preference in the long term is for fragments (+1), I would think it would make more sense to focus on wrapping under the covers / creating fragments on the fly from the plugin.xml 's.
>From a pure e4 standpoint, whatever story is adopted for contributing pure e4 parts, I feel that it would be cleaner (and easier to learn) if one was chosen (plugin.xml vs fragment.e4xmi) instead of having both locations (IMHO).
Right now it isn't clear to me if there is any preference.
JD
On Mon, Apr 22, 2013 at 8:39 AM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:You are both right, there is currently no story for contributing pure e4 parts to the workbench. But does anyone think this is the right answer in the long term? I would much rather see the existing extension points change to accept pure e4 parts, and if any wrapping is required, then *we* do the wrapping under the covers and not have plugin writers explicitly reference or know about them. If we add these wrappers to the platform and advocate that people use them, then when we come up with a better answer next year we would have to ask them to migrate again. And as we all know, once they are available and people are recommending them, it becomes much harder to remove them later. I completely understand the use case and the short term benefit though. Maybe including them in the e4 build and making them easier to consume is a middle ground that lets people use them if they want them, but makes it clear this is not the recommended long term direction? Anyway I leave it to Eric and Paul to make a decision here, it is maybe a good topic for the next e4 meeting.
John
From: Lars Vogel <lars.vogel@xxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date: 04/21/2013 03:21 PM
Subject: Re: [e4-dev] Move wrapper classes to platform?
Sent by: e4-dev-bounces@xxxxxxxxxxx
John,
I agree with Tom. IMHO we have currently no story for IDE plugin developer to use the new programming model without the wrapper classes.I'm more than happy to be corrected, is there a pure E4 way to contribute to the IDE?
On 19 Apr 2013 15:10, "John Arthorne" <John_Arthorne@xxxxxxxxxx> 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/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
_______________________________________________
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
