Re: [e4-dev] More info about the project

[Simon Chemouil <eclipse@xxxxxxxxxxxxxx>]

Vlad Dumitrescu a écrit :
> I asked a similar question on the forums, but they are unavailable at
> the moment and I didn't get to read the answers. I'll write down the
> way I understand the transition process for an existing code base,
> please correct any misunderstandings.

I answered on the newsgroups before they went down, but it seems you 
sorted things out. It might still be interesting to read so I'll forward 
it here.

One thing about Tom's forward compatibility layer: as far as I know, 
it's not bundled as an external project yet (just a few classes to embed 
in your 3.x-compat bundles), and it is incomplete, in the sense that 
some services are not forwarded yet. I think using that forward-compat' 
layer is the right approach for migration, I'm just not sure it makes 
anything easier at this stage :).

Simon

----- Forum message ----
Simon Chemouil wrote :
> Vlad Dumitrescu wrote :
> Hi,
>
> Maybe I'm missing the obvious, but I'm still trying to get all my 
bearings right.
>
> The existing tutorials are targeting RCP applications. I can't find
> anything about developing plugins that will run in the IDE -- the PDE
> tooling targets 3.6 and less and generates old-style plugins...

As it is now, the plan is that IDE plugin developers should develop 
their plugins just as they always did, and make sure they're only 
consuming public API. The only difference is that they should test their 
plugins against both 3.x and 4.0 if they want to be compatible with both 
releases.

The "org.eclipse.e4" API is provisional and is used internally by the 
compatibility layer which is a new implementation of the Eclipse 
Workbench over the Eclipse 4 Application Platform. Adventurous RCP 
developers can benefit from the provisional API because it offers new 
and freer ways to develop apps, but there is not much to gain for plugin 
developers as it is now.

By programming against the provisional API, a plugin developer loses 
compatibility with the 3.x series (unless by using a 4->3 compatibility 
layer), has no guarantee the model or the API won't change, and the gain 
is minimal: the SDK/IDE look is not a problem for plugins, and plugins 
themselves extend current bundles/features that are probably not 
developed using the 4.0 API. If your plugin has dependencies which are 
themselves dependent on 3.x, the interest is really limited. It can be 
interesting when your plugin only depends on eclipse core/ui.

As of today, for a plugin developer, the only advantages I can see are:
 * for fun, learning, etc.
 * taking advantage of the new modeled UI, contexts, DI, etc, but 
keeping in mind that you're forced to go back to the 3.x-style API 
through compatibility for most of the integration with current 
plugins/features (like JDT, Team, etc).


In the long run, of course, the plan is to have a stable 4.x API that 
plugin developers code against, but some features are still missing now 
so the 4.0 story for plugin developers is incomplete.

The early adopters release will allow the 4.0 team to improve the 
compatibility layer by having plugin developers test their 3.6 compliant 
plugins on the 4.0 SDK, and report their bugs.

If you still want to write plugins for 4.0 knowing that they'll likely 
have to mix 3.x and 4.0, but still only be compatible with 4.0, with no 
API stability guarantee... Well you should go for it, because the 4.x 
programming model is much more pleasant imo, but keep in mind that by 
doing so, you will be reaching less users today.

In this case, install model tooling, the E4 SDK and the EMF SDK from the 
p2 update site already preconfigured in the 4.0 SDK ("E4 2010 updates") 
and try to mix 3.x and 4.0 tutorials...

By the way, PDE doesn't "generate" for 3.6. It has a target platform, 
and once you install the 4.0 bundles, you can use them and generate the 
bundles using them from PDE.


Hope this helps,