Project Plan For Equinox, version Galileo
Introduction
The goal of the Equinox project is to be a first class OSGi community and foster the vision of Eclipse as a landscape of bundles. As part of this, it is responsible for developing and delivering the OSGi framework implementation used for all of Eclipse.
This plan is for Equinox as part of the Galileo release in 2009 and attempts to balance the evolution of the technology with the increased need for testing and robustness.
This release of Equinox tackles a number of challenges. As OSGi gains more visibility and Equinox more use, new use-cases and drivers come to the fore -- people are pushing the technology and implementation in new directions. 2009 will also see the release of a new OSGi spec revision. Equinox will implement this spec and several of the new services. Equinox will also deliver runtime technologies including the p2 provisioning platform, the extension registry, integrated security support as well as support for OSGi on on the server.
Release Deliverables
- Equinox source code release, available as versions tagged "R3_5" in the project's
- Framework:
- An OSGi R4.2 Core Framework implementation
- Native launcher and splash screen support
- Compendium Services:
- Application Container - An implementation of the OSGi R4.2 MEG Application Container service.
- Config Admin - An implementation of the OSGi R4.2 Configuration Admin service.
- Device Access Service - An implementation of the OSGi R4.2 Device Access service.
- Declarative Services - An implementation of the OSGi R4.2 Declarative Services specification.
- Event Admin Service - An implementation of the OSGi R4.2 Event Admin Service.
- HTTP Service - An implementation of the OSGi R4.2 HTTP service.
- HTTP Servlet - Generic support for exposing another servlet facility (e.g., an underlying application server) as an OSGi HTTP service.
- IO Connector Service - An implementation of the OSGi R4.2 IO Connector Service.
- Initial Provisioning - An implementation of the OSGi R4.2 Initial Provisioning.
- Log Service - An implementation of the OSGi R4.2 Log service.
- Metatype Service - An implementation of the OSGi R4.2 Metatype service.
- Preferences Service - The Eclipse preference service is an extension of the standard OSGi preference service that adds listeners and the notion of preference scopes.
- User Admin Service - An implementation of the OSGi R4.2 User Admin Service.
- Wire Admin Service - An implementation of the OSGi R4.2 Wire Admin Service.
- p2
- Command line application to mirror repositories.
- Command line application to manage (install / uninstall / update) an eclipse install.
- UI to manage an eclipse installation from within eclipse.
- API to programmatically interact with p2.
- Component model
- Eclipse Extension Registry - The Eclipse extension registry allows bundles to communicate and cooperate using declarative markup and lazy instantiation.
- Equinox Transforms - A framework to provide transformations of bundle resources.
- Security
- Equinox Secure Storage
- Certificate Trust Engine - API for to managing trusted certificates
- Server Side
- HTTP Registry - Support for registering servlets, resources and JSPs via the Eclipse extension registry rather than using the code based OSGi registration mechanisms.
- JSP Registry - Provides a JSP Factory that allows JSP usage with the HTTP Registry.
- Servlet Bridge - Low level hook servlet installed in an existing traditional application server. This servlet launches an embedded Equinox and enables it to handle incoming HTTP requests originally sent to the underlying server.
- HTTP Jetty - A thin layer that exposes an embedded Jetty server as a compliant OSGi HTTP service.
Release Milestones
Release milestones will be occurring at roughly 6 week intervals, and will be aligned with the Galileo Simultaneous Release train.
| M1 | 08/08/2008 | 3.5M1 |
| M2 | 09/19/2008 | 3.5M2 |
| M3 | 10/31/2008 | 3.5M3 |
| M4 | 12/12/2008 | 3.5M4 |
| M5 | 01/30/2009 | 3.5M5 |
| M6 | 03/13/2009 | 3.5M6 (API Freeze) |
| M7 | 05/01/2009 | 3.5M7 (Feature Freeze) |
| RC1 | 05/15/2009 | 3.5RC1 |
| RC2 | 05/22/2009 | 3.5RC2 |
| RC3 | 05/29/2009 | 3.5RC3 |
| RC4 | 06/5/2009 | 3.5RC4 |
| RC5 | 06/12/2009 | 3.5RC5 |
The target date for availability of Equinox 3.5 is:
- Friday June 26, 2009 - Equinox 3.5 Release date (with Galileo)
Target Environments
In order to remain current, each Equinox release targets reasonably current operating environments.
Most of Equinox is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions of Equinox are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.).
In general, the 3.5 release of Equinox is developed for a mix of J2ME Foundation 1.0 and 1.1 JREs. Certain bundles do however use facilities in more recent JRE versions. In such cases, the associated capabilities are available when running on the required JRE.
Appendix 1 contains a table that indicates the class library level required for each bundle.
There are many different implementations of the Java Platform running atop a variety of operating systems. We focus Equinox testing on a handful of popular combinations of operating system and Java Platform; these are our reference platforms. Equinox undoubtedly runs fine in many operating environments beyond the reference platforms we test, including those using Java6 VMs. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Equinox on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Equinox on a reference platform.
Equinox 3.5 is tested and validated on the following reference platforms
(
multiple updates)
(this list is updated over the course of the release cycle):
| Reference Platforms |
Microsoft Windows Vista, x86-32, Win32 running (any of):
|
Microsoft Windows XP, x86-32, Win32 running (any of):
|
Red Hat Enterprise Linux 5.0, x86-32, GTK running (any of):
|
SUSE Linux Enterprise Server 10, x86-32, GTK running (any
of):
|
Microsoft Windows Vista, x86-64, Win32 running (any of):
|
Microsoft Windows XP Professional x64 Edition, x86-64, Win32 running (any of):
|
Red Hat Enterprise Linux 4.0 update 2, x86-64, GTK running:
|
Sun Solaris 10, SPARC, GTK running:
|
HP-UX 11i v2, ia64, Motif 2.1, GTK running:
|
IBM AIX 5.3, Power, Motif 2.1 running:
|
Red Hat Enterprise Linux 5.0, Power, GTK running:
|
SUSE Linux Enterprise Server 10, Power, GTK running:
|
Apple Mac OS X 10.5, Universal, Carbon running:
|
Because Java 1.4.2 and Java5 based platforms are used for most Eclipse development, those platforms are listed here. Although there are teams doing some Java 6 based development we have not included specific Java6 VMs, since they have not yet received the general level of testing we require. We expect that Equinox works fine on other current Java VMs and OSes but we cannot flag these as reference platforms without significant community support for testing them. Especially in areas such as the launcher and OS security integration.
As Equinox is largely headless, there are very few dependencies on window systems. Where there are UI elements (e.g., in the p2 UI), these elements will work on any configuration supported by SWT.
Internationalization
Equinox is designed as the basis for internationalized products. The user interface elements provided by Equinox components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles.
Latin-1 and DBCS locales are supported by Equinox on all reference platforms; BIDI locales are supported by Equinox everywhere but on Motif.
Equinox supports GB 18030 (level 1), the Chinese code page standard, on Windows XP and 2000, Linux/GTK and the Macintosh.
German and Japanese locales are tested.
Compatibility with Previous Releases
Equinox 3.5 will be backward compatible with Equinox 3.4 (and, hence, with 3.3, 3.2, 3.1 and 3.0).
API Contract Compatibility: Equinox 3.5 will be upwards contract-compatible with Equinox 3.4 except in those areas noted in the Equinox 3.5 Migration Guide. Programs that use affected APIs and extension points will need to be ported to Equinox 3.5 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Equinox 3.5 APIs would ensure compliance with Equinox 3.4 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.
Binary (bundle) Compatibility: Equinox 3.5 will be upwards binary-compatible with Equinox 3.4 except in those areas noted in the Equinox 3.5 Migration Guide. Downward bundle compatibility is not supported. Bundles for Equinox 3.5 will not in general be usable in Equinox 3.4. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: Equinox 3.5 will be upwards source-compatible with Equinox 3.4 except in the areas noted in the Equinox 3.5 Migration Guide. This means that source files written to use Equinox 3.4 APIs might successfully compile and run against Equinox 3.5 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Equinox APIs, they will not be usable with an earlier version of Equinox.
Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name or those packages marked with "x-internal=true" or with "x-friends" annotations, are considered implementation details which may vary between operating environment and are subject to change without notice. Client bundles that directly depend on anything other than what is specified in the Equinox API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant bundles.
Themes and Priorities
Plan items listed below were defined according to contributor requirements and the Eclipse Themes and Priorities set forth by the Eclipse Requirements Council. Each plan item covers a feature or API that is to be added to the Equinox deliverables, or some aspect of the Equinox Project that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.
The current status of each plan item is noted:
- Committed plan item - A committed plan item is one that we have decided to address for the release. In bugzilla, this is reflected by having a concrete target milestone assigned.
- Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred. In bugzilla, such items are reflected by having a target milestone "3.5" or "---" assigned.
- Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point. In bugzilla, such items are reflected by having a target milestone "Future" assigned.
Scalability and Performance
New usage scenarios for Equinox require it to be faster, smaller, bigger, ... The technology needs to scale up or down to allow Equinox to scale down to small embedded environments as well as scaling up to large server environments. Monitor overall performance and memory consumption which includes the addition of new performance tests for new features.
- Committed
- Framework
- Investigate places where we can rid the framework of bulky and unnecessary abstraction layers to reduce size and improve performance (service registry abstraction, resolver abstraction etc.). Bug 248352
- p2
- Investigate the places where the installation process is taking too long and see if we can reduce the install time. This includes review of the data structures and algorithms used as well as persistance approaches. 249167.
- Framework
- Proposed
- Framework
- Improve performance of the "uses" directive in the resolver - The OSGi specification provides a modularity framework that ensures consist class spaces when multiple versions of a package is available. In order to ensure a consist class space exporters must specify what other packages they "use" with the "uses" directive. The Equinox Framework correctly implements the "uses" directive but it has been found to cause performance issues in the resolver. Bug 216934
- Framework
- Deferred
- No items.
Robustness
Equinox has become the base for a wide range of platform from embedded to server to desktop and rich client applications. These new scenarios bring new requirements on the execution of Equinox as well as on the programming of its API. The Equinox team will improve the overall robustness by providing APIs for clients where needed and fixing critical bugs. There will also be a focused effort on testability and enhancing the automated test suites.
- Committed
- Framework
- Thread Safety - The Framework lifecycle operations must be thread safe. Several bugs have been reported about thread safety issues when running bundle lifecycle operations from multiple threads. This plan item is to review and fix thread safety issues in the Framework. Bug 247636
- Security
- Improved Test Coverage More complete security tests are needed for the security APIs. Also need to investigate tests suites when the security manager is enabled. Bug 248608
- p2
- Improved Test Coverage Flesh out the p2 test suite to include UI tests, more unit tests as well as better testing of network and communications failure cases. Bug 248788
- Framework
- Proposed
- All
- Improved path and URL support - UNC and URL encoding frequently cause problems. We will identify best practices and coding patterns and make them available for others to use as well as use them throughout the Equinox code base. Bug 248842
- Framework
- API to contribute and get Execution Environment Profiles - The Equinox Framework currently has a set of built-in and supported Execution Environment profiles (e.g. J2SE-1.4, J2SE-1.5 etc.). These profiles are used internally be the Framework to define the packages exported by the running VM. Tooling also needs access to the Execution Environments to place proper visibility rules on the configured VM for a project. API is needed to provide a way to contribute and get the available Execution Environment profiles Bug 240724
- WebStart support on latest VMs - The WebStart support in Equinox needs to be enhanced to load resources outside the jnlp class loader. The current WebStart support makes invalid assumptions on the resources cached by the jnlp class loader. Bug 244311
- Pass arguments to a running Eclipse application. A protocol and framework are needed to allow arguments to be passed from the native launcher to a running instance of eclipse. Bug 178927
- Compendium
- Logging To date the platform has placed tight restrictions on the configuration of existing 3rd party logging frameworks. The goal here is to lift the most important of these restrictions and provide a modular and OSGi friendly integrated approach. Bug 248794
- Server-side
- Support undeploying the servlet bridge - Ensure the servletbridge provides a clean deploy and undeploy environment. The servletbridge does not undeploy cleanly because of its use of a URLClassloader and a restriction on how the VMs "jar"URLConnection holds open the underlying jar file. In particular this prevents us from deleting the framework and servletbridge extension bundles when undeploying. A more deployment friendly class loader is needed here and will likely be useful elsewhere when launching equinox. Bug 190279
- p2
- Improve the robustness of the download operations Several parts of p2 download files (repo content, artifacts, etc.). Even though the robustness is reasonable, there are still room for improvement by providing the ability to checksum the files being downloaded, retry strategies, etc. Bug 248602
- Improve the robustness of the installation in case of failure. There are cases where a failure during certain phase of the installation will cause the system to be left in an inconsistent state (bogus entries in bundles.info, config.ini, etc.). We need to make the transitioning from an install to another robust. Bug 248594
- Investigate the use of alternate http clients. There exist several alternative HTTP client implentations (e.g., Apache, Jetty, ...). Investigate if p2 would benefit from switching to one of these clients in the SDK, the Installer and the Admin UI. Bug 220240
- All
- Deferred
- No items.
Consumability
The diversity of Equinox poses a significant problem to end-users and developers alike. Equinox is extremely flexible and configurable. This makes the hard things possible but in some cases the simple things are not as simple as they might be. The Equinox team will make it easier for users to get the relevant pieces of function, install it on their systems, and configure it for their use. Where there is UI, attention will be paid to making it simple and natural to use. We will also make it easier for developers to use our APIs.
- Committed
- Security
- Improve Security UI Develop useful UIs for functionality delivered in Ganymede, including a certificate management subsystem. Enhance functionality for developing and testing with signed bundles. Bug 153851
- API completeness - Graduate authorization APIs for Trusted Bundle feature, ensure consistency across PKI based use-cases: p2 (Signed Artifacts), Framework (Trusted Bundles) and ECF (SSL). Bug 248586
- p2
- New p2 UI workflows. Based on collaboration with the various user communities, revise the workflow around update and install of new functionality. Bug 248789
- Improve p2 error reporting. When an error occurs, for example, when connecting to a server, downloading a file, etc. the ensure the error messages are specific and directly helpful (e.g. missing file vs unknown host, etc). Bug 248604
- Improve p2 responsiveness. When the user is interacting with p2, ensure that the UI is responsive to cancelation and other inputs. Bug 232440
- Server-side
- Improved configurability for the Jetty Http Service - As the Jetty Http Service used in the platform is applied to broader use-cases we continue to make the necessary changes. In particular we intend to lift the single context per port configuration restriction and allow better access to the underlying error handling mechanisms Jetty provides. Bug 248790
- Security
- Proposed
- p2
- Create API. Currently p2 has considerable provisional API. Review this API and identify consistent subsets to be committed as full API. Focus here should be on specific usage scenarios and care should be taken to not unduly limit progress in places where p2 is still evolving. Bug 248791
- Simplify the addition of repository content p2 is powered by metadata and artifact repositories. Unlike other systems, p2's repositories are solely API driven (there is no schema, and perhaps no XML). As such, we need reasonable tooling and mechanisms to facilitate the publishing of repository content. Bug 248792
- Server-side
- Servletbridge and p2 - Investigate integration and use of p2 in servletbridge-based applications. In particular looking at how to build web applications that come with the full-set of p2 metadata, artifact descriptors and related configuration information consistent with a regular RCP product build. Bug 223256
- p2
- Deferred
- No items.
Future
Eclipse is evolving quickly. New features in the next OSGi specification R4.2 and e4 will drive numerous changes throughout the Equinox project. Considerable effort will be put into updating Equinox to accomodate and exploit these new scenarios.
- Committed
- OSGi standards participation
- The OSGi Alliance, in collaboration with Equinox and other open source communities, is currently revising the Core specifications. As the reference implementation for several parts of the OSGi specifications, Equinox will be updated to implement these new features and changes to the spec. [Framework] Bug 247354 [Compendium] Bug 247355
- Server-side
- Update to the latest Jetty release - Equinox currently hosts both a Jetty 5.1 and Jetty 6.1 based version of the Http Service. For this release we intend to include the latest version of Jetty. In addition to being smaller, faster, and most importantly better supported, more recent versions add support for the latest servlet versions and improved support for communication patterns common to AJAX applications. Bug 248793
- OSGi standards participation
- Proposed
- Extension Registry
- Investigate improvements of the extension registry. Areas of research will include creating user-defined objects instead of configuration elements, expanding ability to programmatically modify the extension registry, and adding support for non-singleton bundles. Due to the size and potential impact of this item, it is considered experimental and might be pushed into later releases. [Components] Bug 248340
- Extension Registry
- Deferred
- No items.
Appendix 1
Appendix 1: Execution Environment by Bundle
In the table below, the "3.5 minimum execution environment" column indicates the minimum Java class library requirements of each bundle for the 3.4 release, where the value is one of:
| Entry | Meaning |
M1.0 |
OSGi Minimum Execution Environment 1.0 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details. |
M1.1 |
OSGi Minimum Execution Environment 1.1 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details. |
F1.0 |
J2ME Foundation 1.0 - indicates that the bundle can only be run on Foundation 1.0 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.0 is a subset of J2SE 1.3. |
F1.1 |
J2ME Foundation 1.1 - indicates that the bundle can only be run on Foundation 1.1 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.1 is a subset of J2SE 1.4. |
1.2 |
J2SE 1.2 - indicates that the bundle can only be run on JSE 1.2 or greater. |
1.3 |
J2SE 1.3 - indicates that the bundle can only be run on JSE 1.3 or greater. |
1.4 |
J2SE 1.4 - indicates that the bundle can only be run on JSE 1.4 or greater. |
1.4/1.5 |
Indicates that the bundle can run on JSE 1.4 or greater, but provides enhanced functionality when run on J2SE 5.0. |
1.5 |
J2SE 5.0 - indicates that the bundle can only be run on JSE 5.0 or greater. |
1.6 |
J2SE 6.0 - indicates that the bundle can only be run on JSE 6.0 or greater. |
| n/a | Unknown at the time of this revision. |
Table of minimum execution environments by bundle. ( multiple updates)
| Bundle | 3.4 |
| javax.servlet.jsp | F1.0 |
| javax.servlet | F1.0 |
| org.apache.commons.el | F1.0 |
| org.apache.commons.logging | F1.0 |
| org.apache.jasper | F1.0 |
| org.eclipse.ecf.filetransfer | F1.0 |
| org.eclipse.ecf.identity | F1.0 |
| org.eclipse.ecf.provider.filetransfer.ssl | 1.4 |
| org.eclipse.ecf.provider.filetransfer | F1.0 |
| org.eclipse.ecf.ssl | 1.4 |
| org.eclipse.ecf | F1.0 |
| org.eclipse.equinox.app | M1.1 |
| org.eclipse.equinox.common | F1.0 |
| org.eclipse.equinox.frameworkadmin.equinox | F1.0 |
| org.eclipse.equinox.frameworkadmin | F1.1 |
| org.eclipse.equinox.http.jetty | F1.0 |
| org.eclipse.equinox.http.registry | F1.0 |
| org.eclipse.equinox.http.servlet | F1.0 |
| org.eclipse.equinox.jsp.jasper.registry | F1.0 |
| org.eclipse.equinox.jsp.jasper | F1.0 |
| org.eclipse.equinox.launcher | F1.0 |
| org.eclipse.equinox.p2.artifact.repository | F1.1 |
| org.eclipse.equinox.p2.console | F1.1 |
| org.eclipse.equinox.p2.core | F1.1 |
| org.eclipse.equinox.p2.director.app | F1.0 |
| org.eclipse.equinox.p2.directorywatcher | F1.0 |
| org.eclipse.equinox.p2.director | F1.1 |
| org.eclipse.equinox.p2.engine | F1.1 |
| org.eclipse.equinox.p2.exemplarysetup | F1.1 |
| org.eclipse.equinox.p2.extensionlocation | F1.1 |
| org.eclipse.equinox.p2.garbagecollector | F1.1 |
| org.eclipse.equinox.p2.jarprocessor | F1.1 |
| org.eclipse.equinox.p2.metadata.generator | 1.4 |
| org.eclipse.equinox.p2.metadata.repository | F1.1 |
| org.eclipse.equinox.p2.metadata | F1.1 |
| org.eclipse.equinox.p2.reconciler.dropins | F1.1 |
| org.eclipse.equinox.p2.touchpoint.eclipse | F1.1 |
| org.eclipse.equinox.p2.touchpoint.natives | F1.1 |
| org.eclipse.equinox.p2.ui.sdk | F1.1 |
| org.eclipse.equinox.p2.ui | F1.1 |
| org.eclipse.equinox.p2.updatechecker | F1.0 |
| org.eclipse.equinox.p2.updatesite | F1.1 |
| org.eclipse.equinox.preferences | F1.0 |
| org.eclipse.equinox.registry | F1.0 |
| org.eclipse.equinox.security.ui | 1.4 |
| org.eclipse.equinox.security | 1.4 |
| org.eclipse.equinox.simpleconfigurator.manipulator | F1.0 |
| org.eclipse.equinox.simpleconfigurator | F1.1 |
| org.eclipse.osgi.services | M1.0 |
| org.eclipse.osgi.util | M1.0 |
| org.eclipse.osgi | M1.1 |
| org.mortbay.jetty | F1.0 |
| org.sat4j.core | 1.4 |
| org.sat4j.pb | 1.4 |
