Community
Participate
Working Groups
Eclipse will be launching an 'e4 ready' campaign soon. To be e4 ready, we have to ensure we use APIs whenever possible and avoid internals. On top of that, we should attempt to structure our code in a way that it can run on both pure e4 and the old Eclipse 3.x line. We should keep this bug as a high level goal and attach any bugs that represent work to it. The goal in the end is to have EGit work with e4 flawlessly.
From my experimenting from April, there doesn't appear to be any compiler errors anyway. As we are "rewriting" the code in org.eclipse.ui.workbench, please avoid using internals from the org.eclipse.ui.workbench at all costs. Admittedly, none were found during Matthias's pass from bug 310933. Please do not hesitate to CC me on any bugs org.eclipse.ui.workbench or org.eclipse.ui.ide that you encounter when testing against the 4.0 SDK.
I'm happy to work with you on this - I'll give you input on this in the next few days.
Created attachment 169476 [details] Example how the project Import is refactored to run without UI-Dependencies Here are some initial thoughts and action items one can get from them: * All UI code is in 1 Bundle * There are a lot of statics used e.g. to Log, Report Status, ... (Activator.*) I think what we should start with is: * Get rid of the static calls and replace them with proper Services passed * Split the UI-Bundle in 2: * org.eclipse.egit.ui: Generic UI-Code - without dependencies on org.eclipse.ui.* - with dependencies on org.eclipse.core.* * org.eclipse.egit.ui.ide3: Code to integrate into 3.x SDK and 4.x SDK (This it the art of single sourceing for 3.x/4.x/e4 :-) Probably using some DI-Technology might be nice thing (though not really necessary) to use. I currently see 2 candidates when it comes to DI: * Guice * e4-DI where both of them have advantages/disadvantages so I think deferring this decision a bit is a good thing. P robably the people who are working on the UI-Code should get added to this bug Chris, I might have time to work with you/them on some initial code but don't have any cycles to really drive this.
With commit 58fa0e8351ebdc2a2c722201cb7d389ff9f0e612 we depend less on Team UI internals now... one step at a time...
I believe we are clean with respect to internals now.
[Batch change] Remove passed Target Milestones If anyone on CC list is going to fix/implement this, feel free to assign a new, post-1.3/2.0, target milestone.
AFAIK this is solved in Eclipse 4.2.1.
true this is fixed since a while
