EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project
Upcoming SlideShare
Loading in...5
×
 

EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project

on

  • 1,746 views

Slides from the EclipseCon 2011 session: EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project...

Slides from the EclipseCon 2011 session: EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project

Abstract:
When it comes to developing a large application from scratch for Airbus Simulation Software, one would surely avoid relying on a framework that's still in beta and with a provisional API. A framework like E4 in early 2010. In this presentation, we will not only explain the reasons of this carefully-thought madness, but also how we succeeded with our approach.

We'll talk about everything we used from stock OSGi services (API-level), Declarative Services, Databinding, E4 Context tricks, extending E4's dependency injection, ... to making a custom build, testing and deployment with Tycho (without PDE's RCP export). But most of all, we will tell you why we did it, what went well and what went wrong, and how we would do it again.

This project has taught us a lot about the best practices with E4 development, we hope to share them and open the discussion on how we see E4's future for RCP applications (and whether you should use E4 for your next RCP application or not).


Talk page on EclipseCon website: https://www.eclipsecon.org/submissions/2011/view_talk.php?id=2103

See the last slide for contact information.

Statistics

Views

Total Views
1,746
Views on SlideShare
1,492
Embed Views
254

Actions

Likes
0
Downloads
43
Comments
0

4 Embeds 254

http://www.eclipsecon.org 206
http://eclipsecon.org 45
http://www.linkedin.com 2
http://eclipsesummit.org 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Enough talk: let's see what it looks like
  • Faire un lien vers Celix / Universal OSGi
  • Faire le rappel sur la terminologie : E4 / Eclipse4 : (We'll just say E4 because we're lazy, but strictly  speaking E4 is the name of incubator project) Faire le lien vers la talk de Tom Schindl
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • Most configuration should use simple annotations Interaction should be easy using the modeled workbench element injected through annotations Views should aim to be POJOs
  • DS : on peut faire bcp avec peu
  • We needed the concept of editors, editor stacks, … not available in the stock E4 Application Model
  • "This is not really about E4, but it's still relate to using Eclipse technologies and it has to be said"
  • "Yes, all OSGi services are dynamic, but" Eclipse Contexts have an OSGi lookup strategy
  • The project was also a testbed for new technologies. The occasion to push ourselves.  With the requirement that it would not impair the final result.

EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial Project Presentation Transcript

  • Benoit Viaud Simon Chemouil Artal Technologies
    • Industrial context
    • Demo
    • E4 overview
    • Using E4 in our context : pros & cons
    • Toolbox
    • Conclusion
    • Industrial context 
      • An Airbus project : Avionic Systems Simulation Monitoring
        • Real time simulation
        • High volume of data (> 1M avionic signals)
        • Used for aircraft integration and certification
    • Why even try E4?
      • Enhance modularity and reuse
      • Look and feel of RCP applications : "not an IDE"
      • Restarting an existing piece of software from scratch
      • Because we've already missed RCP, 5 years ago
    Need for performance
    • We're splitting our monolithic "full packaged" software to finer grained component-based solutions
      • Lot of legacy code (C, C++, Java...)
      • Mainly non-graphical components
      • ... and there is this nice specification for software components called OSGi
      • We looked at E4 as an OSGi-ready RCP framework where we could easily plug our OSGi components
    • We started development first quarter 2010
      • Before the "July release" (E4 0.10.0 / Eclipse 4.0)
      • Provisional API
    • Mitigate the risks
      • Write as little as possible code that depends on E4
        • E4 enables this separation nicely
      • Our views will depend on solid, well-matured techs:
        • SWT, JFace, Eclipse Databinding
    • Plan B :
      • We use/improve on Tom Schindl's forward compatibility layer to run our views in 3.x
  •  
  •  
    • Pure E4 and E4 RCP
        • What do we mean by "pure E4"
        • "Legacy" dependencies   
    • Comparing RCP 3.x with E4 AP
        • Lack of reusable components
    • With that dependency on ViewPart , we can't use the view outside of RCP/IDE
    • Let's move to E4 Application Platform!
    • Let's start with RCP3.x
    FooView
    • public class FooView extends ViewPart {
      • public void createPartControl(Composite parent) {
      • // create widgets on parent
      • }
    • }
    • Now it's a POJO
      • But we need to guide the framework...
    • Switching to the E4 Application Platform...
    FooView
    • Now it's a POJO
      • But how do we get that parent composite instance?
    FooView
    • public class FooView {
      • @PostConstruct
      • public void createUI(Composite parent) {
      • // create widgets on parent
      • }
    • }
  • FooView DI
    • DI stands for Dependency Injection
      • Pretty standard these days
    • Like in RCP 3.x, FooView is an object managed by an IoC container
      • « Inversion of Control »
      • But this container does more!
    • @PostConstruct
      • « After you're done calling new on me, call this method with the proper parameters, or fail if you can't »
      • Parameter name: Composite.class.getName()
    Where from??
    • Eclipse Contexts
      • Hierarchical map
      • ~ Symbol table
    • Default source for injection
    • Somehow the map has the proper Composite object for FooView
    • How exactly? :-)
    FooView Eclipse Context DI
    • The Application Model
      • An EMF model
      • There's a lot more to it.
    • It says which class contributes to which element (view, handler, ...)
    FooView Eclipse Context DI Application model
    • Application Model elements are readily available
    • Objects from external sources (OSGi services, properties…) can be injected
      • Very useful for configuration!
    • Of course, it's the other way around
    • And we can get more stuff injected
    FooView Eclipse Context
    • public class FooView {
    • @Inject MPart part;
      • @Inject
      • public void setLogService(LogService ls)
      • {
      • }
    • }
    DI Application model
    • Entry points to interact with the E4 Application Platform
    • Different services for different tasks
      • Eventing (backed by the OSGi EventAdmin)
      • Selection Service
      • Part Service
      • Model Service
    • Some services are still missing
      • Notification, authentication, scheduling jobs, ...
    • Services but not OSGi services!
      • Defined in the EclipseContext
    NEW
    • "So we started testing, coding... etc, etc "
  •  
    • Application skeleton
      • Add only what you like, the way you like
        • No more hacks to remove unwanted contributions
      • An EMF model (using E4 Tooling)
    • Add your different features in the appropriate view
      • Contribute an extension to the main model to add your feature
      • Sounds familiar?
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
    • Our recipe:
      • Business layer (services) 
      • POM (aggregator service): no SWT/JFace dep.
      • UI (POM consumer, databinding, contribution to the model)    
    • What's special in E4 about it?
      • Easy with DI
        • OSGi services injection
        • Interaction with the application model
      • Related: Service outjection would make whiteboard easy
    Advice #1: Keep business logic away from the E4 and Eclipse Contexts. Inject OSGi services instead then profit. Account for the absence and dynamism of a service, because UI creation doesn't wait.
    • Most of it is declarative services
      • Component oriented programming made simple
        • But powerful
      • Consumption and registration
    • From UI bundles
      • Consumption only so far
      • @Inject
      • public void setMyService(MyService s) { }
      • Limited support out of the box
    • Sometimes, OSGi API
      • When service registration depends on conditions expressible only in Java or when properties are dynamic
      • Better avoid if possible
      • We've extended the base model
          • E4 benefits from the EMF project greatly
    Advice #2: if you think your application will grow to a significant size, extend E4Application from the start, so that you don't have to edit your model namespaces later.
    • The Application Model is an EMF Model
      • The meta-model defines the base elements for an application
    • The full MAESTRO stack consists of more than one hundred OSGi bundles.
      • There are different ways to compose them and build different applications
    • We made sure our non-E4 dependent bundles can be used outside of Eclipse and Equinox
      • No Require-Bundle , no non-standard headers, etc
    • OSGi offered solutions to many of our problems
      • Many useful specifications & open source implementations
    Advice #3: Maybe OSGi has a standard solution for your problem as well: component configuration, bundle isolation, etc? Look over at Apache as well!
  •  
    • Injecting "dynamic OSGi services"
      • What are dynamic services?
    • Potential solutions
      • Patching Eclipse Contexts
      • Extending E4 DI : @Dynamic
    • We're using @Dynamic
    • @Inject
    • public void setMyService(@Dynamic MyService s) { }
      • Still some corner cases, but works pretty well
    Advice #4: If you need to inject objects from a custom source, extend E4 DI and define a new annotation as a marker. E4 DI extensions are simply... OSGi services!
    • Commands & Handlers similar to 3.x but with DI in mind
      • Binding an UI element's enablement (menu, button) to the @CanExecute method of the handler
    • Handlers are re-evaluated on context change
    • But sometimes you need them to react to external events...
      • Like the arrival of an OSGi service, or a change in the application somewhere
    • What we'd like…
    @CanExecute boolean canExecute(@Optional LogService service) { return service != null; }
    • The workaround…
    public static final String SERVICE_OK = "logservice.ok"; //$NON-NLS-1$ @Inject void refreshExternal(@Dynamic LogService logger, IEclipseContext context) { context.set(SERVICE_OK, logger != null ? Boolean.TRUE : Boolean.FALSE); } @CanExecute boolean canExecute(@Optional @Named(SERVICE_OK) Boolean serviceOK) { return Boolean.TRUE.equals(serviceOK); }
    • Of course, we tore our hair out on some problems like...
      • Retrieving a workbench service early
      • Missing imports in E4 CSS
      • Menu ordering & dynamism
    • But all-in-all, relatively few problems, they were worked around eventually
      • E4 AP July Release was not for the faint of heart!
      • Yet its simple programming model made up for it
  •  
    • Sonatype/Eclipse Tycho
      • A Maven plugin that mimics PDE build
      • Avoiding dev/prod environment mismatch
      • Works well, but feels odd in the Maven world
      • Limited support for the "POM-first" approach
    • Maven-bundle-plugin
      • The Maven OSGi plugin developed by the Felix community
      • Part of our move to a more generic OSGi workflow
      • We want Import-Package and we want it now!
        • Bnd under the hood does its magic
      • We want to deploy to Nexus, get our dependencies there as well
    Wish #1: All hail Import-Package Wish #2: Eclipse Bundles at Maven Central!
    • Unit tests wherever possible
      • We don't have nearly enough, but the central pieces are tested
    • Integration tests playing scenarios (« functional tests ») but we don't test the UI
      • OSGi testing lacks love :-)
    • Unit tests wherever possible
      • We don't have nearly enough, but the central pieces are tested
    • Integration tests playing scenarios (« functional tests ») but we don't test the UI
      • OSGi testing lacks love :-)
    • Went with PDE/Tycho tests
      • For Tycho, we generate a target platform with Maven for each test bundle
    • EVALUATED
    • Pax Exam (1.x branch) :
      • Some weird bugs, poor integration with Eclipse (debugging+hotswap)
    • JUnit4OSGi:
      • Only JUnit3 support, we're on Junit4
    • Bnd Testing Harness:
      • No support for Maven, difficult to add because Bnd works with relative paths
    • PDE Plug-in tests:
      • Best integration with Eclipse, offline build with Tycho
    • Unit tests wherever possible
      • We don't have nearly enough, but the central pieces are tested
    • Integration tests playing scenarios (« functional tests ») but we don't test the UI
      • OSGi testing lacks love :-)
    • Went with PDE/Tycho tests
      • For Tycho, we generate a target platform with Maven for each test bundle
    • Special sauce:
        • We use PDE but Manifests/DS XML are generated by Maven-Bundle-Plugin
        • Including during development phase
    Wish #3: An even more OSGi-friendly PDE with Bnd-like support
  • Final words
    • E4 AP is the right direction
        • Way, way simpler than Eclipse 3.X
        • Standardization on @Inject
        • The Application Model, use of EMF and Eclipse contexts are very nice
    • We knew what to expect for the July release
        • It's an early adopter preview, we signed for it and it went surprisingly well
    • There's still room for improvement :-)
        • We would like a bigger gap with Eclipse RCP 3.X, especially in making E4AP a first-class OSGi citizen
        • Make E4 the framework for rich OSGi applications
        • Some discussions in progress
    • We'll continue improving MAESTRO
      • And update the E4 version we target: POJOs make that easier
    • Discuss and contribute to the OSGi bits of E4
    • Call for a new generation of RCP components "pure E4"
      • We do have a few goodies and ideas to share but little time to package it all, come and discuss :-)
    • We expect to see many more developers using the E4 Application Platform!
  • (and feel free to come for more) Simon Chemouil [email_address] simach on Twitter Benoit Viaud [email_address]