Embed Size (px)
DESCRIPTION
Slides from the EclipseCon 2011 session: EclipseCon 2011 - An Early Adopter's Retrospective on an E4 Industrial ProjectAbstract: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=2103See the last slide for contact information.
Citation preview
1
Benoit ViaudSimon Chemouil
Artal Technologies
2
1. Industrial context
2. Demo
3. E4 overview
4. Using E4 in our context : pros & cons
5. Toolbox
6. Conclusion
3
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
4
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
5
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
6
7
8
Pure E4 and E4 RCPWhat do we mean by "pure E4""Legacy" dependencies
Comparing RCP 3.x with E4 APLack of reusable components
9
FooViewFooView
public class FooView extends ViewPart {
public void createPartControl(Composite parent) {
// create widgets on parent}
}
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
10
FooViewFooView
Now it's a POJO◦ But we need to guide the framework...
Switching to the E4 Application Platform...
11
FooViewFooView
public class FooView {
@PostConstructpublic void createUI(Composite parent) {
// create widgets on parent}
}
Now it's a POJO◦ But how do we get that parent composite
instance?
12
FooViewFooView
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??
13
FooViewFooView
Eclipse ContextEclipse Context
DI
Eclipse Contexts◦Hierarchical map◦~ Symbol table
Default source for injection
Somehow the map has the proper Composite object for FooView
How exactly? :-)
14
FooViewFooView
Eclipse ContextEclipse Context
DI
Application model
Application model
The Application Model◦ An EMF model◦ There's a lot more
to it.
It says which class contributes to which element (view, handler, ...)
15
FooViewFooView
Eclipse ContextEclipse Context
public class FooView {
@Inject MPart part;
@Injectpublic void setLogService(LogService ls){
}}
DI
Application model
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 aroundAnd we can get more stuff injected
16
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
NEW
17
"So we started testing, coding... etc, etc "
18
19
1. Application skeleton◦ Add only what you like, the way you like
No more hacks to remove unwanted contributions◦ An EMF model (using E4 Tooling)
2. Add your different features in the appropriate view◦ Contribute an extension to the main model to add your
feature◦ Sounds familiar?
20
21
22
23
24
25
26
27
28
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.
29
Most of it is declarative services◦ Component oriented programming made simple
But powerful◦ Consumption and registration
From UI bundles◦ Consumption only so far@Injectpublic 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
30
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
We've extended the base model E4 benefits from the EMF project
greatly
31
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!
32
33
Injecting "dynamic OSGi services"◦What are dynamic services?
Potential solutions◦Patching Eclipse Contexts◦Extending E4 DI : @Dynamic
We're using @Dynamic@Injectpublic 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!
34
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
35
What we'd like…
@CanExecute
boolean canExecute(@Optional LogService service) {
return service != null;
}
36
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);
}
37
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
38
39
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-PackageWish #2: Eclipse Bundles at Maven Central!
40
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 :-)
41
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
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
42
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
43
Special sauce:We use PDE but Manifests/DS XML are generated by
Maven-Bundle-PluginIncluding during development phase
Wish #3: An even more OSGi-friendly PDE with Bnd-like support
44
Final words
45
E4 AP is the right directionWay, way simpler than Eclipse 3.XStandardization on @InjectThe Application Model, use of EMF and Eclipse contexts are very
nice
We knew what to expect for the July releaseIt'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 citizenMake E4 the framework for rich OSGi applicationsSome discussions in progress
46
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!
47
(and feel free to come for more)
Simon [email protected]
simach on Twitter
Benoit [email protected]
