Home » Eclipse Projects » Eclipse 4 » Migration from 3.x to Eclipse 4
| Migration from 3.x to Eclipse 4 [message #883826] |
Sat, 09 June 2012 14:06  |
 Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi,
different questions and approaches have been written for a migration
path from Eclipse 3.x to Eclipse 4. Especially interesting are the
options to mix both approaches.
I would like to wrap up all the stuff I have found and kindly ask you
for your comments. I plan to wrap all findings into a tutorial and link
it in the Eclipse wiki.
These would be the options to write Eclipse RCP applications in the future:
1. Pure Compatibility Layer
Advantages:
- if application API clean, no action required (except product
configuration)
- Features such as CSS Styling available
Disadvantages:
- No Workbench model and DI
2. Pure Eclipse 4 Application
Advantages:
- All Eclipse 4 Features such as Workbench Model, DI, etc.
Disadvantages:
- No reuse of existing 3.x components, such as Console, Error Log, About
dialogs, JDT Editors, View Menue etc. until they are migrated.
3. Eclipse 4 Application with Eclipse 3.x components
Advantages:
- All Eclipse 4 Features such as Workbench Model, DI, etc.
Disadvantages:
- Probably most of the 3.x bundles will not work out of the box, as the
require the workbench and therefore the compatibility layer.
4. Compatibility Layer + pure Eclipse 4 bundles
Advantages:
- if existing application is API clean, no intial action required
(except product configuration)
- New Elements can be written following the Eclipse 4 programming model
and be added to the existing application
Disadvantages:
- Currently neither fragments, nor processors can be used to do this
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
have to copy the legacymodel.e4xmi and modify it to add your own views.
There were comments, that a goal of 4.3 might be to better support this
option by allowing fragments and processors to be used.
- Following different programming models in the same application might
be confusing
- No real success stories?
5. Use the forward compatibility layer + compatibility layer
Implement Views and editors by subclassing the compatibility
implementations from Tom Schindl. Register these views like in 3.x
Advantages:
- if existing application is API clean, no intial action required
(except product configuration)
- New Views can be written following the Eclipse 4 programming model and
be added to the existing application
Disadvantages:
- Only works for views and editors?
- Elements are no POJOs
Have I missed anything, or is anything wrong? Currently my favorite
option would be 4. or 5.
Looking forward to your comments.
Cheers
jonas
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #883843 is a reply to message #883826] |
Sat, 09 June 2012 15:05  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 09.06.12 16:06, schrieb Jonas Helming:
> Hi,
> different questions and approaches have been written for a migration
> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
> options to mix both approaches.
> I would like to wrap up all the stuff I have found and kindly ask you
> for your comments. I plan to wrap all findings into a tutorial and link
> it in the Eclipse wiki.
> These would be the options to write Eclipse RCP applications in the future:
>
> 1. Pure Compatibility Layer
> Advantages:
> - if application API clean, no action required (except product
> configuration)
> - Features such as CSS Styling available
> Disadvantages:
> - No Workbench model and DI
Well if you run in Eclipse 4 with compat mode you can get access to the
workbench model but not through API yet. See how the e4 bridge gets
access to the IEclipseContext and Workbench Model
>
> 2. Pure Eclipse 4 Application
> Advantages:
> - All Eclipse 4 Features such as Workbench Model, DI, etc.
> Disadvantages:
> - No reuse of existing 3.x components, such as Console, Error Log, About
> dialogs, JDT Editors, View Menue etc. until they are migrated.
>
Right.
> 3. Eclipse 4 Application with Eclipse 3.x components
> Advantages:
> - All Eclipse 4 Features such as Workbench Model, DI, etc.
> Disadvantages:
> - Probably most of the 3.x bundles will not work out of the box, as the
> require the workbench and therefore the compatibility layer.
>
This is true for UI components yes. For core stuff like e.g. JDT-Core
they don't need any compat layer. I can only point you to my SimpleIDE
and lately JavaFX-IDE experiments who show that all core stuff from egit
to jdt is available.
> 4. Compatibility Layer + pure Eclipse 4 bundles
> Advantages:
> - if existing application is API clean, no intial action required
> (except product configuration)
> - New Elements can be written following the Eclipse 4 programming model
> and be added to the existing application
> Disadvantages:
> - Currently neither fragments, nor processors can be used to do this
> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
> have to copy the legacymodel.e4xmi and modify it to add your own views.
> There were comments, that a goal of 4.3 might be to better support this
> option by allowing fragments and processors to be used.
Sure processors and fragments work! The problem is one of timeing but
e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
compat layer through a processor (see
org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
There's no subclassing involved - but that only works for "views"
because for editors not enough meta information is provided in the
workbench model.
So while not all usecases are possible some are as the "live model
editor" shows you.
> - Following different programming models in the same application might
> be confusing
Correct but it allows you to singlesource if that's something you aim at
> - No real success stories?
Right beside the Live Modeleditor which integrates into:
* pure e4
* Eclipse 4.x SDK
>
> 5. Use the forward compatibility layer + compatibility layer
> Implement Views and editors by subclassing the compatibility
> implementations from Tom Schindl. Register these views like in 3.x
Let's call it e4 bridge and *not* forward compat layer.
> Advantages:
> - if existing application is API clean, no intial action required
> (except product configuration)
> - New Views can be written following the Eclipse 4 programming model and
> be added to the existing application
> Disadvantages:
> - Only works for views and editors?
Correct though I wanted to make it work for Handlers too I didn't had
time to implement it but I don't see a problem getting it to work.
> - Elements are no POJOs
Why are elements not POJOs?
>
> Have I missed anything, or is anything wrong? Currently my favorite
> option would be 4. or 5.
> Looking forward to your comments.
Not as far as I know ;-)
Tom
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #883854 is a reply to message #883843] |
Sat, 09 June 2012 15:39 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Thank you Tom for commenting, for 5. I meant the views are no POJOs as
the inherit from the compatibility implementation.
Am 09.06.2012 17:05, schrieb Tom Schindl:
> Am 09.06.12 16:06, schrieb Jonas Helming:
>> Hi,
>> different questions and approaches have been written for a migration
>> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
>> options to mix both approaches.
>> I would like to wrap up all the stuff I have found and kindly ask you
>> for your comments. I plan to wrap all findings into a tutorial and link
>> it in the Eclipse wiki.
>> These would be the options to write Eclipse RCP applications in the future:
>>
>> 1. Pure Compatibility Layer
>> Advantages:
>> - if application API clean, no action required (except product
>> configuration)
>> - Features such as CSS Styling available
>> Disadvantages:
>> - No Workbench model and DI
>
> Well if you run in Eclipse 4 with compat mode you can get access to the
> workbench model but not through API yet. See how the e4 bridge gets
> access to the IEclipseContext and Workbench Model
>
>>
>> 2. Pure Eclipse 4 Application
>> Advantages:
>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>> Disadvantages:
>> - No reuse of existing 3.x components, such as Console, Error Log, About
>> dialogs, JDT Editors, View Menue etc. until they are migrated.
>>
>
> Right.
>
>> 3. Eclipse 4 Application with Eclipse 3.x components
>> Advantages:
>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>> Disadvantages:
>> - Probably most of the 3.x bundles will not work out of the box, as the
>> require the workbench and therefore the compatibility layer.
>>
>
> This is true for UI components yes. For core stuff like e.g. JDT-Core
> they don't need any compat layer. I can only point you to my SimpleIDE
> and lately JavaFX-IDE experiments who show that all core stuff from egit
> to jdt is available.
>
>> 4. Compatibility Layer + pure Eclipse 4 bundles
>> Advantages:
>> - if existing application is API clean, no intial action required
>> (except product configuration)
>> - New Elements can be written following the Eclipse 4 programming model
>> and be added to the existing application
>> Disadvantages:
>> - Currently neither fragments, nor processors can be used to do this
>> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
>> have to copy the legacymodel.e4xmi and modify it to add your own views.
>> There were comments, that a goal of 4.3 might be to better support this
>> option by allowing fragments and processors to be used.
>
> Sure processors and fragments work! The problem is one of timeing but
> e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
> compat layer through a processor (see
> org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
>
> There's no subclassing involved - but that only works for "views"
> because for editors not enough meta information is provided in the
> workbench model.
>
> So while not all usecases are possible some are as the "live model
> editor" shows you.
>
>> - Following different programming models in the same application might
>> be confusing
>
> Correct but it allows you to singlesource if that's something you aim at
>
>> - No real success stories?
>
> Right beside the Live Modeleditor which integrates into:
> * pure e4
> * Eclipse 4.x SDK
>
>>
>> 5. Use the forward compatibility layer + compatibility layer
>> Implement Views and editors by subclassing the compatibility
>> implementations from Tom Schindl. Register these views like in 3.x
>
> Let's call it e4 bridge and *not* forward compat layer.
>
>> Advantages:
>> - if existing application is API clean, no intial action required
>> (except product configuration)
>> - New Views can be written following the Eclipse 4 programming model and
>> be added to the existing application
>> Disadvantages:
>> - Only works for views and editors?
>
> Correct though I wanted to make it work for Handlers too I didn't had
> time to implement it but I don't see a problem getting it to work.
>
>> - Elements are no POJOs
>
> Why are elements not POJOs?
>
>>
>> Have I missed anything, or is anything wrong? Currently my favorite
>> option would be 4. or 5.
>> Looking forward to your comments.
>
> Not as far as I know ;-)
>
> Tom
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #883861 is a reply to message #883843] |
Sat, 09 June 2012 15:57 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Am 09.06.2012 17:05, schrieb Tom Schindl:
> Am 09.06.12 16:06, schrieb Jonas Helming:
>> Hi,
>> different questions and approaches have been written for a migration
>> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
>> options to mix both approaches.
>> I would like to wrap up all the stuff I have found and kindly ask you
>> for your comments. I plan to wrap all findings into a tutorial and link
>> it in the Eclipse wiki.
>> These would be the options to write Eclipse RCP applications in the future:
>>
>> 1. Pure Compatibility Layer
>> Advantages:
>> - if application API clean, no action required (except product
>> configuration)
>> - Features such as CSS Styling available
>> Disadvantages:
>> - No Workbench model and DI
>
> Well if you run in Eclipse 4 with compat mode you can get access to the
> workbench model but not through API yet. See how the e4 bridge gets
> access to the IEclipseContext and Workbench Model
>
>>
>> 2. Pure Eclipse 4 Application
>> Advantages:
>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>> Disadvantages:
>> - No reuse of existing 3.x components, such as Console, Error Log, About
>> dialogs, JDT Editors, View Menue etc. until they are migrated.
>>
>
> Right.
>
>> 3. Eclipse 4 Application with Eclipse 3.x components
>> Advantages:
>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>> Disadvantages:
>> - Probably most of the 3.x bundles will not work out of the box, as the
>> require the workbench and therefore the compatibility layer.
>>
>
> This is true for UI components yes. For core stuff like e.g. JDT-Core
> they don't need any compat layer. I can only point you to my SimpleIDE
> and lately JavaFX-IDE experiments who show that all core stuff from egit
> to jdt is available.
>
>> 4. Compatibility Layer + pure Eclipse 4 bundles
>> Advantages:
>> - if existing application is API clean, no intial action required
>> (except product configuration)
>> - New Elements can be written following the Eclipse 4 programming model
>> and be added to the existing application
>> Disadvantages:
>> - Currently neither fragments, nor processors can be used to do this
>> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
>> have to copy the legacymodel.e4xmi and modify it to add your own views.
>> There were comments, that a goal of 4.3 might be to better support this
>> option by allowing fragments and processors to be used.
>
> Sure processors and fragments work! The problem is one of timeing but
> e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
> compat layer through a processor (see
> org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
>
> There's no subclassing involved - but that only works for "views"
> because for editors not enough meta information is provided in the
> workbench model.
I have experiemented a little bit with this. I have used the RCP Mail
app as an RCP 3.x application. I think processors are only executed if
the have the parameter MApplication, at least they are not executed for
MWindow or MPerspective. This makes it possible to insert handlers or
commands. However if I want to add a view, I would have to manually
browse thru the model to find the right place to insert something. It is
possible but this is not very robust. Am I missing something?
>
> So while not all usecases are possible some are as the "live model
> editor" shows you.
>
>> - Following different programming models in the same application might
>> be confusing
>
> Correct but it allows you to singlesource if that's something you aim at
>
>> - No real success stories?
>
> Right beside the Live Modeleditor which integrates into:
> * pure e4
> * Eclipse 4.x SDK
>
>>
>> 5. Use the forward compatibility layer + compatibility layer
>> Implement Views and editors by subclassing the compatibility
>> implementations from Tom Schindl. Register these views like in 3.x
>
> Let's call it e4 bridge and *not* forward compat layer.
>
>> Advantages:
>> - if existing application is API clean, no intial action required
>> (except product configuration)
>> - New Views can be written following the Eclipse 4 programming model and
>> be added to the existing application
>> Disadvantages:
>> - Only works for views and editors?
>
> Correct though I wanted to make it work for Handlers too I didn't had
> time to implement it but I don't see a problem getting it to work.
>
>> - Elements are no POJOs
>
> Why are elements not POJOs?
>
>>
>> Have I missed anything, or is anything wrong? Currently my favorite
>> option would be 4. or 5.
>> Looking forward to your comments.
>
> Not as far as I know ;-)
>
> Tom
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #883865 is a reply to message #883861] |
Sat, 09 June 2012 16:15 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Views are added as MPartDescriptors - this is what the view-extension
point is translated in. Contributing a view directly to a perspective is
not possible yet because of the timing issue explain in the bug you
referenced.
Tom
Am 09.06.12 17:57, schrieb Jonas Helming:
> Am 09.06.2012 17:05, schrieb Tom Schindl:
>> Am 09.06.12 16:06, schrieb Jonas Helming:
>>> Hi,
>>> different questions and approaches have been written for a migration
>>> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
>>> options to mix both approaches.
>>> I would like to wrap up all the stuff I have found and kindly ask you
>>> for your comments. I plan to wrap all findings into a tutorial and link
>>> it in the Eclipse wiki.
>>> These would be the options to write Eclipse RCP applications in the
>>> future:
>>>
>>> 1. Pure Compatibility Layer
>>> Advantages:
>>> - if application API clean, no action required (except product
>>> configuration)
>>> - Features such as CSS Styling available
>>> Disadvantages:
>>> - No Workbench model and DI
>>
>> Well if you run in Eclipse 4 with compat mode you can get access to the
>> workbench model but not through API yet. See how the e4 bridge gets
>> access to the IEclipseContext and Workbench Model
>>
>>>
>>> 2. Pure Eclipse 4 Application
>>> Advantages:
>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>> Disadvantages:
>>> - No reuse of existing 3.x components, such as Console, Error Log, About
>>> dialogs, JDT Editors, View Menue etc. until they are migrated.
>>>
>>
>> Right.
>>
>>> 3. Eclipse 4 Application with Eclipse 3.x components
>>> Advantages:
>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>> Disadvantages:
>>> - Probably most of the 3.x bundles will not work out of the box, as the
>>> require the workbench and therefore the compatibility layer.
>>>
>>
>> This is true for UI components yes. For core stuff like e.g. JDT-Core
>> they don't need any compat layer. I can only point you to my SimpleIDE
>> and lately JavaFX-IDE experiments who show that all core stuff from egit
>> to jdt is available.
>>
>>> 4. Compatibility Layer + pure Eclipse 4 bundles
>>> Advantages:
>>> - if existing application is API clean, no intial action required
>>> (except product configuration)
>>> - New Elements can be written following the Eclipse 4 programming model
>>> and be added to the existing application
>>> Disadvantages:
>>> - Currently neither fragments, nor processors can be used to do this
>>> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
>>> have to copy the legacymodel.e4xmi and modify it to add your own views.
>>> There were comments, that a goal of 4.3 might be to better support this
>>> option by allowing fragments and processors to be used.
>>
>> Sure processors and fragments work! The problem is one of timeing but
>> e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
>> compat layer through a processor (see
>> org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
>>
>> There's no subclassing involved - but that only works for "views"
>> because for editors not enough meta information is provided in the
>> workbench model.
>
> I have experiemented a little bit with this. I have used the RCP Mail
> app as an RCP 3.x application. I think processors are only executed if
> the have the parameter MApplication, at least they are not executed for
> MWindow or MPerspective. This makes it possible to insert handlers or
> commands. However if I want to add a view, I would have to manually
> browse thru the model to find the right place to insert something. It is
> possible but this is not very robust. Am I missing something?
>
>>
>> So while not all usecases are possible some are as the "live model
>> editor" shows you.
>>
>>> - Following different programming models in the same application might
>>> be confusing
>>
>> Correct but it allows you to singlesource if that's something you aim at
>>
>>> - No real success stories?
>>
>> Right beside the Live Modeleditor which integrates into:
>> * pure e4
>> * Eclipse 4.x SDK
>>
>>>
>>> 5. Use the forward compatibility layer + compatibility layer
>>> Implement Views and editors by subclassing the compatibility
>>> implementations from Tom Schindl. Register these views like in 3.x
>>
>> Let's call it e4 bridge and *not* forward compat layer.
>>
>>> Advantages:
>>> - if existing application is API clean, no intial action required
>>> (except product configuration)
>>> - New Views can be written following the Eclipse 4 programming model and
>>> be added to the existing application
>>> Disadvantages:
>>> - Only works for views and editors?
>>
>> Correct though I wanted to make it work for Handlers too I didn't had
>> time to implement it but I don't see a problem getting it to work.
>>
>>> - Elements are no POJOs
>>
>> Why are elements not POJOs?
>>
>>>
>>> Have I missed anything, or is anything wrong? Currently my favorite
>>> option would be 4. or 5.
>>> Looking forward to your comments.
>>
>> Not as far as I know ;-)
>>
>> Tom
>
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #883867 is a reply to message #883854] |
Sat, 09 June 2012 16:18 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
But those View/Editor-Class are super small all they have is a
constructor which informs the parent about the DI-enabled POJO the real
implementation is found in.
We could easily bring in View/Editors using IExecuteableExtensionFactory
if you don't want to have this minimal glue class but I encountered even
in 3.x some strange problems with this approach (can remember though
which one exactly).
Tom
Am 09.06.12 17:39, schrieb Jonas Helming:
> Thank you Tom for commenting, for 5. I meant the views are no POJOs as
> the inherit from the compatibility implementation.
>
> Am 09.06.2012 17:05, schrieb Tom Schindl:
>> Am 09.06.12 16:06, schrieb Jonas Helming:
>>> Hi,
>>> different questions and approaches have been written for a migration
>>> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
>>> options to mix both approaches.
>>> I would like to wrap up all the stuff I have found and kindly ask you
>>> for your comments. I plan to wrap all findings into a tutorial and link
>>> it in the Eclipse wiki.
>>> These would be the options to write Eclipse RCP applications in the
>>> future:
>>>
>>> 1. Pure Compatibility Layer
>>> Advantages:
>>> - if application API clean, no action required (except product
>>> configuration)
>>> - Features such as CSS Styling available
>>> Disadvantages:
>>> - No Workbench model and DI
>>
>> Well if you run in Eclipse 4 with compat mode you can get access to the
>> workbench model but not through API yet. See how the e4 bridge gets
>> access to the IEclipseContext and Workbench Model
>>
>>>
>>> 2. Pure Eclipse 4 Application
>>> Advantages:
>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>> Disadvantages:
>>> - No reuse of existing 3.x components, such as Console, Error Log, About
>>> dialogs, JDT Editors, View Menue etc. until they are migrated.
>>>
>>
>> Right.
>>
>>> 3. Eclipse 4 Application with Eclipse 3.x components
>>> Advantages:
>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>> Disadvantages:
>>> - Probably most of the 3.x bundles will not work out of the box, as the
>>> require the workbench and therefore the compatibility layer.
>>>
>>
>> This is true for UI components yes. For core stuff like e.g. JDT-Core
>> they don't need any compat layer. I can only point you to my SimpleIDE
>> and lately JavaFX-IDE experiments who show that all core stuff from egit
>> to jdt is available.
>>
>>> 4. Compatibility Layer + pure Eclipse 4 bundles
>>> Advantages:
>>> - if existing application is API clean, no intial action required
>>> (except product configuration)
>>> - New Elements can be written following the Eclipse 4 programming model
>>> and be added to the existing application
>>> Disadvantages:
>>> - Currently neither fragments, nor processors can be used to do this
>>> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
>>> have to copy the legacymodel.e4xmi and modify it to add your own views.
>>> There were comments, that a goal of 4.3 might be to better support this
>>> option by allowing fragments and processors to be used.
>>
>> Sure processors and fragments work! The problem is one of timeing but
>> e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
>> compat layer through a processor (see
>> org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
>>
>> There's no subclassing involved - but that only works for "views"
>> because for editors not enough meta information is provided in the
>> workbench model.
>>
>> So while not all usecases are possible some are as the "live model
>> editor" shows you.
>>
>>> - Following different programming models in the same application might
>>> be confusing
>>
>> Correct but it allows you to singlesource if that's something you aim at
>>
>>> - No real success stories?
>>
>> Right beside the Live Modeleditor which integrates into:
>> * pure e4
>> * Eclipse 4.x SDK
>>
>>>
>>> 5. Use the forward compatibility layer + compatibility layer
>>> Implement Views and editors by subclassing the compatibility
>>> implementations from Tom Schindl. Register these views like in 3.x
>>
>> Let's call it e4 bridge and *not* forward compat layer.
>>
>>> Advantages:
>>> - if existing application is API clean, no intial action required
>>> (except product configuration)
>>> - New Views can be written following the Eclipse 4 programming model and
>>> be added to the existing application
>>> Disadvantages:
>>> - Only works for views and editors?
>>
>> Correct though I wanted to make it work for Handlers too I didn't had
>> time to implement it but I don't see a problem getting it to work.
>>
>>> - Elements are no POJOs
>>
>> Why are elements not POJOs?
>>
>>>
>>> Have I missed anything, or is anything wrong? Currently my favorite
>>> option would be 4. or 5.
>>> Looking forward to your comments.
>>
>> Not as far as I know ;-)
>>
>> Tom
>
|
|
|
| Re: Migration from 3.x to Eclipse 4 [message #884301 is a reply to message #883867] |
Sun, 10 June 2012 18:56 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Has the bridge feature moved? I cannot find it on the last build of the
e4 project.
Cheers
Jonas
Am 09.06.2012 18:18, schrieb Tom Schindl:
> But those View/Editor-Class are super small all they have is a
> constructor which informs the parent about the DI-enabled POJO the real
> implementation is found in.
>
> We could easily bring in View/Editors using IExecuteableExtensionFactory
> if you don't want to have this minimal glue class but I encountered even
> in 3.x some strange problems with this approach (can remember though
> which one exactly).
>
> Tom
>
> Am 09.06.12 17:39, schrieb Jonas Helming:
>> Thank you Tom for commenting, for 5. I meant the views are no POJOs as
>> the inherit from the compatibility implementation.
>>
>> Am 09.06.2012 17:05, schrieb Tom Schindl:
>>> Am 09.06.12 16:06, schrieb Jonas Helming:
>>>> Hi,
>>>> different questions and approaches have been written for a migration
>>>> path from Eclipse 3.x to Eclipse 4. Especially interesting are the
>>>> options to mix both approaches.
>>>> I would like to wrap up all the stuff I have found and kindly ask you
>>>> for your comments. I plan to wrap all findings into a tutorial and link
>>>> it in the Eclipse wiki.
>>>> These would be the options to write Eclipse RCP applications in the
>>>> future:
>>>>
>>>> 1. Pure Compatibility Layer
>>>> Advantages:
>>>> - if application API clean, no action required (except product
>>>> configuration)
>>>> - Features such as CSS Styling available
>>>> Disadvantages:
>>>> - No Workbench model and DI
>>>
>>> Well if you run in Eclipse 4 with compat mode you can get access to the
>>> workbench model but not through API yet. See how the e4 bridge gets
>>> access to the IEclipseContext and Workbench Model
>>>
>>>>
>>>> 2. Pure Eclipse 4 Application
>>>> Advantages:
>>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>>> Disadvantages:
>>>> - No reuse of existing 3.x components, such as Console, Error Log, About
>>>> dialogs, JDT Editors, View Menue etc. until they are migrated.
>>>>
>>>
>>> Right.
>>>
>>>> 3. Eclipse 4 Application with Eclipse 3.x components
>>>> Advantages:
>>>> - All Eclipse 4 Features such as Workbench Model, DI, etc.
>>>> Disadvantages:
>>>> - Probably most of the 3.x bundles will not work out of the box, as the
>>>> require the workbench and therefore the compatibility layer.
>>>>
>>>
>>> This is true for UI components yes. For core stuff like e.g. JDT-Core
>>> they don't need any compat layer. I can only point you to my SimpleIDE
>>> and lately JavaFX-IDE experiments who show that all core stuff from egit
>>> to jdt is available.
>>>
>>>> 4. Compatibility Layer + pure Eclipse 4 bundles
>>>> Advantages:
>>>> - if existing application is API clean, no intial action required
>>>> (except product configuration)
>>>> - New Elements can be written following the Eclipse 4 programming model
>>>> and be added to the existing application
>>>> Disadvantages:
>>>> - Currently neither fragments, nor processors can be used to do this
>>>> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486) Instead you
>>>> have to copy the legacymodel.e4xmi and modify it to add your own views.
>>>> There were comments, that a goal of 4.3 might be to better support this
>>>> option by allowing fragments and processors to be used.
>>>
>>> Sure processors and fragments work! The problem is one of timeing but
>>> e.g. the CSS-Spy and Live Modeltooling integrate themselves in the the
>>> compat layer through a processor (see
>>> org.eclipse.e4.tools.emf.liveeditor.ModelProcessor).
>>>
>>> There's no subclassing involved - but that only works for "views"
>>> because for editors not enough meta information is provided in the
>>> workbench model.
>>>
>>> So while not all usecases are possible some are as the "live model
>>> editor" shows you.
>>>
>>>> - Following different programming models in the same application might
>>>> be confusing
>>>
>>> Correct but it allows you to singlesource if that's something you aim at
>>>
>>>> - No real success stories?
>>>
>>> Right beside the Live Modeleditor which integrates into:
>>> * pure e4
>>> * Eclipse 4.x SDK
>>>
>>>>
>>>> 5. Use the forward compatibility layer + compatibility layer
>>>> Implement Views and editors by subclassing the compatibility
>>>> implementations from Tom Schindl. Register these views like in 3.x
>>>
>>> Let's call it e4 bridge and *not* forward compat layer.
>>>
>>>> Advantages:
>>>> - if existing application is API clean, no intial action required
>>>> (except product configuration)
>>>> - New Views can be written following the Eclipse 4 programming model and
>>>> be added to the existing application
>>>> Disadvantages:
>>>> - Only works for views and editors?
>>>
>>> Correct though I wanted to make it work for Handlers too I didn't had
>>> time to implement it but I don't see a problem getting it to work.
>>>
>>>> - Elements are no POJOs
>>>
>>> Why are elements not POJOs?
>>>
>>>>
>>>> Have I missed anything, or is anything wrong? Currently my favorite
>>>> option would be 4. or 5.
>>>> Looking forward to your comments.
>>>
>>> Not as far as I know ;-)
>>>
>>> Tom
>>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 15:41:24 GMT 2024
Powered by FUDForum. Page generated in 0.04613 seconds |
] 
Search
Help
Register
Login
Home
