The Eclipse ecosystem provides a number of projects to support software development and systems engineering. However, in the open source community, one important aspect of the engineering process has been very much neglected until now - Requirements Management. The "Requirements Modeling Framework" (RMF) is a proposed open source project under the "Model Development Tools Project".

The goal of RMF is to provide the community with a solid implementation of the OMG ReqIF (Requirements Interchange Format) standard upon which various requirements management tools can be built as well as integrated. RMF plans to provide a means for data exchange between tools, an EMF based meta-model, infrastructure tooling and user interface.

The talk would provide first-hand information about the new project, its scope and current state. The session would also be chance to inform yourself about the importance of this standardization effort in requirements management domain.

Software consumers in domains like aerospace have to face different issues than the traditional software industry when creating Embedded Software:

• The software embedded in a spatial mission needs to be supported for more than 40 years in response to the lifetime of the mission.
• The software embedded in an aircraft flight command system must be "certified" according to aircraft safety standards, including the tooling used to produce this software.

Thus, during the whole life-cycle of the product, those Software consumers need maturity assessment and long lasting support for their tooling.

These concerns are also relevant in other safety regulated environments like railway or energy, and also for other domains with long life products like telco.

We will tell you the story of these users who decided to adopt Open Source more than five years ago to tackle these strategic issues with Topcased. And how they are extending their ecosystem with the creation of OPEES, an initiative for the Long Term Support of open source tooling for Embedded Software.

We will also go through the evolution of the Eclipse Foundation during this period of time, and how it introduced the notion of Long Term Support and Industrial Working Groups.

Good news is that these stories meet now with the creation of the OPEES IWG inside Eclipse.

Today we face an increasing number of bundles in our OSGI runtimes. Especially if we use a lot of third party bundles coming from different vendors there might be some "rogue bundles" included.
Bundles are rogues because they may have some special conflicting requirements towards other bundles in our runtime or they bring unwanted side effects to other bundles.
For example
- a bundle may require to set or set itself some global state in an other bundle, such as some static java variables wich conflicts with other bundles.
- a bundle may export an already existing package.
- a set of bundles has its dependencies defined in an inconsistent way.

How can we handle these shortcomings and conflicts in our OSGI runtime? With last years session "Runtime surgery" we looked at the possibilities to change the behaviour of existing bundles we want to reuse. The examples from above show the need to also influence the resolution process of bundles. With OSGI 4.3 comes the org.osgi.framework.hooks.resolver.ResolverHook API that can be used to separate bundles from each other.
This talk shows how to create compartments in the OSGI runtime that can be resolved independently from the rest of the runtime, using the new ResolverHook API.