diff --git a/docs/Eclipse4_Migration.md b/docs/Eclipse4_Migration.md
new file mode 100644
index 00000000000..1b879c2c307
--- /dev/null
+++ b/docs/Eclipse4_Migration.md
@@ -0,0 +1,825 @@
+# Eclipse 4 Migration Guide
+
+## Introduction
+
+This guide helps you migrate your Eclipse 3.x (E3) RCP application to the Eclipse 4 (E4) application model. It assumes you have already set up a basic E4 application structure and now need guidance on how to gradually upgrade existing E3 components to their E4 counterparts.
+
+For a broader understanding of E4 concepts, see the [Eclipse4 RCP FAQ](Eclipse4_RCP_FAQ.md).
+
+## Prerequisites
+
+Before you begin migrating individual components, ensure you have:
+
+1. **A Model Fragment**: All E4 contributions are made through model fragments. If you haven't created one yet, see [Creating Model Fragments](#creating-model-fragments).
+
+2. **Required Dependencies**: Your MANIFEST.MF should include appropriate E4 dependencies:
+ ```
+ Require-Bundle: org.eclipse.e4.ui.model.workbench,
+ org.eclipse.e4.ui.workbench,
+ org.eclipse.e4.core.di,
+ org.eclipse.e4.ui.di,
+ org.eclipse.e4.core.contexts
+ ```
+
+3. **Annotation Support**: For dependency injection to work, add to your MANIFEST.MF:
+ ```
+ Import-Package: jakarta.annotation;version="1.1.0",
+ jakarta.inject;version="1.0.0"
+ ```
+
+4. **Preserve Element IDs**: When migrating from E3 to E4, always use the same IDs! The E3 command/view/handler ID should match the E4 elementId to ensure compatibility and avoid breaking existing configurations.
+
+### Creating Model Fragments
+
+Model fragments allow you to contribute UI elements to the E4 application model. To create a model fragment:
+
+1. **Create the fragment file**: Create a `fragment.e4xmi` file in your bundle's root or in a `model/` folder.
+
+2. **Register in plugin.xml**: Add an extension to your plugin.xml:
+ ```xml
+
+
+
+
+ ```
+
+3. **Edit with E4 Model Editor**: Open the fragment.e4xmi with the "Eclipse 4 Model Editor" (right-click → Open With → E4 Model Editor).
+
+The fragment structure typically looks like:
+```xml
+
+
+
+
+```
+
+For more details, see [Eclipse4 Model](Eclipse4_Model.md).
+
+## Migrate a Command
+
+Commands define semantic actions that can be triggered by various UI elements (menu items, toolbar buttons, key bindings).
+
+### E3 Approach
+
+In E3, commands are defined in plugin.xml using the `org.eclipse.ui.commands` extension point:
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+### E4 Approach
+
+In E4, commands are defined in the application model (fragment.e4xmi) as MCommand elements:
+
+```xml
+
+
+
+
+
+```
+
+**Note**: In the model editor:
+- The `elementId` serves as the command identifier (equivalent to E3's `id`)
+- The `commandName` is the display name
+
+### Migration Steps
+
+1. **Open fragment.e4xmi** in the E4 Model Editor
+
+2. **Add a Model Fragment**:
+ - In the overview pane, select "Model Fragments"
+ - Click "Add" → Select "StringModelFragment"
+ - Set Feature Name: `commands`
+ - Set Parent Element ID: `org.eclipse.e4.legacy.ide.application` (or your application ID)
+
+3. **Add Command**:
+ - In the fragment details, click "Add" under Elements
+ - Select "Command"
+ - Set Element Id: Use your E3 command id (e.g., `com.example.mycommand`)
+ - Set Command Name: The display name
+ - Set Description: Optional description
+
+4. **Add Parameters** (if needed):
+ - Select your command
+ - In the "Parameters" section, click "Add"
+ - Set Element Id and Name for each parameter
+
+5. **Remove E3 registration**: Once tested, remove the corresponding `` element from your plugin.xml
+
+6. **Update references**: Any code that references the command by ID should continue to work, as the element ID matches the E3 command ID.
+
+## Migrate a Handler
+
+Handlers contain the actual implementation code that executes when a command is invoked.
+
+### E3 Approach
+
+In E3, handlers are registered in plugin.xml using the `org.eclipse.ui.handlers` extension point:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+The handler class extends `AbstractHandler`:
+
+```java
+package com.example.handlers;
+
+import org.eclipse.core.commands.AbstractHandler;
+import org.eclipse.core.commands.ExecutionEvent;
+import org.eclipse.core.commands.ExecutionException;
+import org.eclipse.ui.IWorkbenchWindow;
+import org.eclipse.ui.handlers.HandlerUtil;
+
+public class MyHandler extends AbstractHandler {
+
+ @Override
+ public Object execute(ExecutionEvent event) throws ExecutionException {
+ IWorkbenchWindow window = HandlerUtil.getActiveWorkbenchWindow(event);
+ // Implementation here
+ return null;
+ }
+}
+```
+
+### E4 Approach
+
+In E4, handlers are defined in the model fragment and use dependency injection. The handler class uses `@Execute` annotation:
+
+```xml
+
+
+
+```
+
+The handler class uses dependency injection:
+
+```java
+package com.example.handlers;
+
+import jakarta.inject.Named;
+import org.eclipse.e4.core.di.annotations.Execute;
+import org.eclipse.e4.core.di.annotations.CanExecute;
+import org.eclipse.e4.ui.services.IServiceConstants;
+import org.eclipse.swt.widgets.Shell;
+
+public class MyHandler {
+
+ @Execute
+ public void execute(@Named(IServiceConstants.ACTIVE_SHELL) Shell shell) {
+ // Implementation here
+ // Dependencies are injected automatically
+ }
+
+ @CanExecute
+ public boolean canExecute() {
+ // Replaces E3's enabledWhen expressions
+ return true;
+ }
+}
+```
+
+### Migration Steps
+
+1. **Define the handler in the model**:
+ - Open fragment.e4xmi in the E4 Model Editor
+ - Add a Model Fragment with Feature Name: `handlers`
+ - Set Parent Element ID: `org.eclipse.e4.legacy.ide.application` (or scope it to a specific part/window)
+ - Add a Handler element
+ - Set Contribution URI: `bundleclass://your.bundle.id/com.example.handlers.MyHandler`
+
+2. **Link to command**:
+ - If the command is in the same fragment, you can reference it directly
+ - If it's in a different fragment/application, create an import:
+ - Select "Imports" in the fragment
+ - Add a Command import
+ - Set the Element ID to your command's ID
+ - Set the handler's Command reference to your command
+
+3. **Convert handler class**:
+ - Remove `extends AbstractHandler` and `implements IHandler`
+ - Remove `execute(ExecutionEvent)` method signature
+ - Add `@Execute` annotation to execution method
+ - Use dependency injection instead of HandlerUtil:
+ ```java
+ // E3:
+ IWorkbenchWindow window = HandlerUtil.getActiveWorkbenchWindow(event);
+ ISelection selection = HandlerUtil.getCurrentSelection(event);
+
+ // E4:
+ @Execute
+ public void execute(@Named(IServiceConstants.ACTIVE_SELECTION) ISelection selection,
+ @Named(IServiceConstants.ACTIVE_SHELL) Shell shell) {
+ // Use injected values
+ }
+ ```
+
+4. **Convert enablement logic**:
+ - Replace `enabledWhen` expressions with `@CanExecute` method:
+ ```java
+ @CanExecute
+ public boolean canExecute(@Named(IServiceConstants.ACTIVE_SELECTION) ISelection selection) {
+ return selection != null && !selection.isEmpty();
+ }
+ ```
+
+5. **Handle active context** (replacement for `activeWhen`):
+ - In E4, handlers are scoped to their containing model element
+ - Global handlers: Add to application level
+ - Part-specific handlers: Add to the part's handler list
+ - Window-specific handlers: Add to the window's handler list
+
+6. **Remove E3 registration**: Remove the `` element from plugin.xml
+
+7. **Update MANIFEST.MF**: Ensure you import the injection packages:
+ ```
+ Import-Package: jakarta.inject;version="1.0.0",
+ jakarta.annotation;version="1.1.0"
+ ```
+
+### Common Injection Patterns for Handlers
+
+**Important**: Always inject dependencies in the `@Execute` and `@CanExecute` methods rather than using field injection. This ensures you always receive the most recent values from the context, which is critical for handlers that may be executed multiple times with different contexts.
+
+```java
+// Active shell
+@Named(IServiceConstants.ACTIVE_SHELL) Shell shell
+
+// Active part
+@Named(IServiceConstants.ACTIVE_PART) MPart part
+
+// Active selection
+@Named(IServiceConstants.ACTIVE_SELECTION) ISelection selection
+
+// Eclipse context
+IEclipseContext context
+
+// Part service
+EPartService partService
+
+// Model service
+EModelService modelService
+
+// Command service (for parameters)
+@Execute
+public void execute(@Named("parameter.name") String paramValue) {
+ // paramValue contains the command parameter
+}
+```
+
+## Migrate a View
+
+Views are the primary UI containers in Eclipse applications.
+
+### E3 Approach
+
+In E3, views are registered in plugin.xml using the `org.eclipse.ui.views` extension point:
+
+```xml
+
+
+
+
+
+
+```
+
+The view class extends `ViewPart`:
+
+```java
+package com.example.views;
+
+import org.eclipse.swt.widgets.Composite;
+import org.eclipse.ui.part.ViewPart;
+
+public class MyView extends ViewPart {
+
+ public static final String ID = "com.example.myview";
+
+ @Override
+ public void createPartControl(Composite parent) {
+ // Create UI here
+ }
+
+ @Override
+ public void setFocus() {
+ // Set focus to a control
+ }
+}
+```
+
+### E4 Approach
+
+In E4, views become MPart elements defined through PartDescriptors in the model:
+
+```xml
+
+
+ View
+
+
+```
+
+The view class uses dependency injection:
+
+```java
+package com.example.views;
+
+import jakarta.annotation.PostConstruct;
+import jakarta.annotation.PreDestroy;
+import jakarta.inject.Inject;
+import org.eclipse.swt.widgets.Composite;
+import org.eclipse.e4.ui.di.Focus;
+
+public class MyView {
+
+ @Inject
+ public MyView() {
+ // Constructor - dependencies can be injected here
+ }
+
+ @PostConstruct
+ public void createPartControl(Composite parent) {
+ // Create UI here - same as E3
+ // parent is automatically injected
+ }
+
+ @Focus
+ public void setFocus() {
+ // Set focus to a control
+ }
+
+ @PreDestroy
+ public void dispose() {
+ // Cleanup resources
+ }
+}
+```
+
+### Migration Steps
+
+1. **Create PartDescriptor in the model**:
+ - Open fragment.e4xmi in E4 Model Editor
+ - Add a Model Fragment with Feature Name: `descriptors`
+ - Set Parent Element ID: `org.eclipse.e4.legacy.ide.application`
+ - Add a PartDescriptor element
+ - Set Element Id: Use your E3 view ID (e.g., `com.example.myview`)
+ - Set Label: The view name
+ - Set Contribution URI: `bundleclass://your.bundle.id/com.example.views.MyView`
+ - Set Icon URI: `platform:/plugin/your.bundle.id/icons/view.png` (if applicable)
+ - Set Category: For grouping in the Show View menu
+ - Set Closeable: `true` if view can be closed
+ - Set Allow Multiple: `false` typically (set `true` if multiple instances allowed)
+
+2. **Add View tag**:
+ - In the PartDescriptor details, go to "Tags" section
+ - Add tag: `View` (this identifies it as a view for the Show View menu)
+
+3. **Convert view class**:
+ - Remove `extends ViewPart`
+ - Change method signatures:
+ ```java
+ // E3:
+ public void createPartControl(Composite parent)
+
+ // E4:
+ @PostConstruct
+ public void createPartControl(Composite parent)
+ ```
+ - Change focus method:
+ ```java
+ // E3:
+ public void setFocus()
+
+ // E4:
+ @Focus
+ public void setFocus()
+ ```
+ - Add disposal if needed:
+ ```java
+ @PreDestroy
+ public void dispose() {
+ // Cleanup
+ }
+ ```
+
+4. **Replace getSite() calls** with dependency injection:
+ ```java
+ // E3:
+ IWorkbenchPartSite site = getSite();
+ ISelectionProvider provider = site.getSelectionProvider();
+
+ // E4:
+ @Inject
+ ESelectionService selectionService;
+
+ @PostConstruct
+ public void createPartControl(Composite parent) {
+ // Use selectionService.setSelection() instead
+ }
+ ```
+
+5. **Update other service access**:
+ ```java
+ // E3:
+ getSite().getWorkbenchWindow().getActivePage();
+
+ // E4:
+ @Inject
+ EPartService partService;
+ ```
+
+6. **Remove E3 registration**: Remove the `` element from plugin.xml
+
+7. **Test the view**:
+ - The view should appear in Window → Show View menu
+ - It should be openable via `EPartService.showPart()`
+
+### Common View Injection Patterns
+
+```java
+// Parent composite (for createPartControl)
+@PostConstruct
+public void createPartControl(Composite parent)
+
+// Part itself
+@Inject MPart part;
+
+// Part service
+@Inject EPartService partService;
+
+// Selection service
+@Inject ESelectionService selectionService;
+
+// Menu service
+@Inject EMenuService menuService;
+
+// Receiving selection changes
+@Inject
+public void setSelection(@Named(IServiceConstants.ACTIVE_SELECTION)
+ @Optional ISelection selection) {
+ // Reacts to selection changes
+}
+
+// Accessing part properties
+@Inject MPart part;
+// part.getProperties().put("key", "value");
+```
+
+## Migrate a Menu
+
+Menus in Eclipse can be main menus, view menus, context menus, or toolbar items.
+
+### E3 Approach
+
+In E3, menu contributions are made through various extension points:
+
+**Main Menu Contribution:**
+```xml
+
+
+
+
+
+```
+
+**Toolbar Contribution:**
+```xml
+
+
+
+
+
+
+
+
+```
+
+**Context Menu Contribution:**
+```xml
+
+
+
+
+
+
+
+
+
+
+
+```
+
+### E4 Approach
+
+In E4, menu contributions are defined in the model through menu contributions:
+
+**Main Menu Contribution:**
+```xml
+
+
+
+
+
+
+
+```
+
+**Toolbar Contribution:**
+```xml
+
+
+
+
+
+
+
+```
+
+**Dynamic Menu with Visibility Expression:**
+```xml
+
+
+
+```
+
+Define the expression in plugin.xml or as a core expression in the model.
+
+### Migration Steps
+
+#### For Main Menu Items:
+
+1. **Create menu contribution fragment**:
+ - Open fragment.e4xmi in E4 Model Editor
+ - Add Model Fragment with Feature Name: `menuContributions`
+ - Set Parent Element ID: `org.eclipse.e4.legacy.ide.application`
+ - Add MenuContribution element
+ - Set Parent ID: `org.eclipse.ui.main.menu` (for main menu)
+ - Set Position In Parent: `after=additions` (or other position)
+
+2. **Add menu structure**:
+ - For a submenu: Add Menu element as a child
+ - Set Element Id, Label, Mnemonics
+ - For menu items: Add HandledMenuItem as children
+ - Set Element Id, Label
+ - Link to command (via import if necessary)
+
+3. **Link to commands**:
+ - Create command imports if commands are defined elsewhere
+ - Set the Command reference on each HandledMenuItem
+
+#### For Toolbar Items:
+
+1. **Create toolbar contribution**:
+ - Same as menu, but set Parent ID: `org.eclipse.ui.main.toolbar`
+ - Add ToolBar element as child
+ - Add HandledToolItem elements as toolbar children
+ - Set Icon URI: `platform:/plugin/your.bundle.id/icons/icon.png`
+
+#### For Context Menus:
+
+1. **Identify the popup menu ID**:
+ - For views: Usually the view's element ID
+ - For general context menus: `org.eclipse.ui.popup.any`
+ - For specific contexts: Check existing plugin.xml registrations
+
+2. **Create popup menu contribution**:
+ - Set Parent ID to the popup menu ID
+ - Add HandledMenuItem elements
+ - Add visibility expressions if needed
+
+3. **Programmatic context menu** (for view-specific):
+ ```java
+ @PostConstruct
+ public void createPartControl(Composite parent,
+ EMenuService menuService,
+ MPart part) {
+ // Create viewer or control
+ TableViewer viewer = new TableViewer(parent);
+
+ // Register context menu
+ menuService.registerContextMenu(viewer.getControl(),
+ part.getElementId());
+ }
+ ```
+
+#### For Visibility/Enablement:
+
+1. **Using Core Expressions**:
+ - Define expressions in plugin.xml:
+ ```xml
+
+
+
+
+
+
+
+ ```
+
+2. **In the model**:
+ - Add visibleWhen element to menu items
+ - Reference the expression by ID
+
+3. **Programmatic enablement** (via handler):
+ ```java
+ @CanExecute
+ public boolean canExecute(@Named(IServiceConstants.ACTIVE_SELECTION)
+ ISelection selection) {
+ return selection != null && !selection.isEmpty();
+ }
+ ```
+
+#### Final Steps:
+
+1. **Remove E3 registrations**: Remove `` elements from plugin.xml
+
+2. **Test menu visibility and enablement**: Ensure menus appear in correct locations and respond to context
+
+3. **Verify icons**: Check that icon URIs are correct (use `platform:/plugin/` scheme)
+
+### Common Menu URI Patterns
+
+For reference, common menu parent IDs:
+
+- Main menu: `org.eclipse.ui.main.menu`
+- Main toolbar: `org.eclipse.ui.main.toolbar`
+- File menu: `file`
+- Edit menu: `edit`
+- Help menu: `help`
+- Any popup: `org.eclipse.ui.popup.any`
+- View-specific popup: Use the view's element ID
+
+Position qualifiers:
+- `after=additions`
+- `before=additions`
+- `after=someMenuId`
+- `first`
+- `last`
+
+## Testing Your Migration
+
+After migrating components, test thoroughly:
+
+1. **Launch Configuration**:
+ - Use `-clearPersistedState` to ensure model changes are loaded
+ - Use `-persistState false` during development
+
+2. **Verify Functionality**:
+ - Commands execute correctly
+ - Handlers receive proper context
+ - Views display and update properly
+ - Menus appear in correct locations
+
+3. **Check Injection**:
+ - Enable tracing: `-Dorg.eclipse.e4.core.di.debug=true`
+ - Watch for injection errors in the log
+
+4. **Test Lifecycle**:
+ - Open/close views
+ - Execute commands multiple times
+ - Check resource disposal (no memory leaks)
+
+## Common Migration Pitfalls
+
+1. **Forgot @PostConstruct**: Methods won't be called without the annotation
+2. **Wrong parent ID**: Menu items won't appear if parent ID is incorrect
+3. **Missing imports**: Commands/handlers from other fragments need imports
+4. **Persisted state**: Use `-clearPersistedState` when testing model changes
+5. **Class not injectable**: Handler/view class must have a public no-arg constructor or an @Inject constructor
+6. **Shell auto-generation**: Always use `@Named(IServiceConstants.ACTIVE_SHELL)` to avoid getting a new Shell
+
+## Additional Resources
+
+- [Eclipse4 RCP FAQ](Eclipse4_RCP_FAQ.md) - Common questions and answers
+- [Eclipse4 RCP Dependency Injection](Eclipse4_RCP_Dependency_Injection.md) - DI details
+- [Eclipse4 RCP Contexts](Eclipse4_RCP_Contexts.md) - Context hierarchy
+- [Eclipse4 Model](Eclipse4_Model.md) - Contributing to the E4 application model
+- [Platform Command Framework](PlatformCommandFramework.md) - Command details
+- [Menu Contributions](Menu_Contributions.md) - E3 menu contribution patterns
+
+## Contributing
+
+If you find issues with this guide or have suggestions for improvement, please contribute:
+1. Open an issue at the [Eclipse Platform UI repository](https://github.com/eclipse-platform/eclipse.platform.ui)
+2. Submit a pull request with improvements
+3. Share your migration experiences to help others
+
+---
+
+*This guide is maintained as part of the Eclipse Platform UI project and evolves with the codebase.*
diff --git a/docs/Eclipse4_Model.md b/docs/Eclipse4_Model.md
new file mode 100644
index 00000000000..b0c98467fb4
--- /dev/null
+++ b/docs/Eclipse4_Model.md
@@ -0,0 +1,123 @@
+# Eclipse 4 Model
+
+## Contributing to the E4 Application Model
+
+This document provides guidance on contributing to the Eclipse 4 application model through model fragments and extensions.
+
+## Model Fragments
+
+Model fragments allow you to contribute UI elements to the E4 application model declaratively. All E4 contributions are made through model fragments rather than traditional Eclipse 3.x extension points.
+
+### Creating a Model Fragment
+
+1. **Create the fragment file**: Create a `fragment.e4xmi` file in your bundle's root or in a `model/` folder.
+
+2. **Register in plugin.xml**: Add an extension to your plugin.xml:
+ ```xml
+
+
+
+
+ ```
+
+3. **Edit with E4 Model Editor**: Open the fragment.e4xmi with the "Eclipse 4 Model Editor" (right-click → Open With → E4 Model Editor).
+
+### Fragment Structure
+
+A basic fragment structure looks like:
+
+```xml
+
+
+
+
+```
+
+### Types of Contributions
+
+Model fragments can contribute various elements:
+
+- **Commands**: Define semantic actions
+- **Handlers**: Implement command behavior
+- **Parts (Views/Editors)**: UI containers via PartDescriptors
+- **Menu Contributions**: Menus, toolbars, and context menus
+- **Key Bindings**: Keyboard shortcuts
+- **Addons**: Application lifecycle hooks
+
+### String Model Fragments
+
+The most common fragment type is `StringModelFragment`, which targets a specific feature of a parent element:
+
+```xml
+
+
+
+```
+
+Key attributes:
+- **featurename**: The model feature to contribute to (e.g., `commands`, `handlers`, `descriptors`, `menuContributions`)
+- **parentElementId**: The ID of the parent element (typically your application ID or `org.eclipse.e4.legacy.ide.application`)
+
+### Importing Model Elements
+
+To reference elements defined in other fragments or the application model:
+
+1. Select "Imports" in the fragment editor
+2. Add the appropriate import type (Command, Part, etc.)
+3. Set the Element ID to match the target element's ID
+
+**Note**: Only fragments can import elements from the application model or other fragments. Application models cannot import from fragments.
+
+### Element IDs
+
+- Element IDs (`elementId`) are used to identify model elements
+- Unlike EMF's internal `xmi:id`, element IDs should be human-readable
+- For certain elements (like Commands), element IDs must be unique
+- When migrating from E3, always preserve the original IDs
+
+### Model Editor Tips
+
+- Use the E4 Model Editor (included in Eclipse IDE for RCP development)
+- The editor provides validation and helps ensure proper model structure
+- Changes to fragments require `-clearPersistedState` flag during development to see effects
+
+## Application Model
+
+The application model (`Application.e4xmi`) defines the core structure of your E4 application:
+
+- **Windows**: Top-level containers
+- **Perspectives**: Layouts of parts
+- **Part Stacks**: Containers for parts (views/editors)
+- **Trim Bars**: Toolbars and status bars
+- **Handlers**: Global command handlers
+- **Bindings**: Key bindings
+- **Snippets**: Reusable UI fragments
+
+## Additional Resources
+
+- [Eclipse4 RCP FAQ](Eclipse4_RCP_FAQ.md) - Common questions about E4
+- [Eclipse4 Migration Guide](Eclipse4_Migration.md) - Migrating from E3 to E4
+- [Eclipse Wiki - Contributing to the Model](https://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Contributing_to_the_Model) - Detailed Wiki article
+
+## Best Practices
+
+1. **Use meaningful element IDs**: Choose descriptive IDs that clearly indicate purpose
+2. **Keep fragments focused**: Create separate fragments for different contribution types
+3. **Document your model**: Add descriptions to help others understand your contributions
+4. **Test with -clearPersistedState**: Model changes only apply when state is cleared
+5. **Preserve E3 IDs when migrating**: Maintain compatibility by keeping the same IDs
+
+---
+
+*This guide is maintained as part of the Eclipse Platform UI project and evolves with the codebase.*
diff --git a/docs/Eclipse4_RCP_FAQ.md b/docs/Eclipse4_RCP_FAQ.md
index f9bd37ccda1..98e402042f6 100644
--- a/docs/Eclipse4_RCP_FAQ.md
+++ b/docs/Eclipse4_RCP_FAQ.md
@@ -5,6 +5,8 @@ Eclipse4/RCP/FAQ
Adopting the Eclipse 4 Application Platform
-------------------------------------------
+> **Migrating from Eclipse 3.x?** See the [Eclipse 4 Migration Guide](Eclipse4_Migration.md) for step-by-step instructions on migrating commands, handlers, views, and menus from E3 to E4.
+
### How do the Eclipse 3.x and 4.x programming models differ?
Conceptually, the models aren't very different. The Eclipse 4 programming model is strongly influenced by the Eclipse 3.x model, but rectifies some of the mistakes that were only realized in hindsight. If you are a proficient Eclipse 3.x RCP developer, then most concepts and approaches will be fairly familiar.