Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox Planning - 3.3"
| Line 4: | Line 4: | ||
** Implementation | ** Implementation | ||
** Tooling | ** Tooling | ||
| + | |||
* Update Manager | * Update Manager | ||
** The update manager code ownership is migrating from Toronto to Ottawa. We need to keep on top of bug reports and current problems to ensure that nothing slips by for 3.2.1. | ** The update manager code ownership is migrating from Toronto to Ottawa. We need to keep on top of bug reports and current problems to ensure that nothing slips by for 3.2.1. | ||
** We need to investigate refactoring the JarProcessor code. It was put into the Update bundles at the end of the 3.2 cycle but is more generally useful. | ** We need to investigate refactoring the JarProcessor code. It was put into the Update bundles at the end of the 3.2 cycle but is more generally useful. | ||
** JarProcessor - might be some more work here w.r.t. JAR signing and nested JARs | ** JarProcessor - might be some more work here w.r.t. JAR signing and nested JARs | ||
| + | |||
* Provisioning | * Provisioning | ||
** Prototype | ** Prototype | ||
| Line 14: | Line 16: | ||
*** Small installer download? | *** Small installer download? | ||
*** Dynamic web content that builds zip? | *** Dynamic web content that builds zip? | ||
| + | |||
* PDE/Build | * PDE/Build | ||
** Continue investigation into inter-operability with Maven | ** Continue investigation into inter-operability with Maven | ||
** Incremental building | ** Incremental building | ||
| + | |||
* Component Model | * Component Model | ||
** The programming model. | ** The programming model. | ||
| Line 22: | Line 26: | ||
** We want to get people off the Platform class. | ** We want to get people off the Platform class. | ||
** Need to have something easy for people to use when they migrate their code. | ** Need to have something easy for people to use when they migrate their code. | ||
| − | * Framework (refactor/etc) | + | |
| + | * OSGi Framework (refactor/etc) | ||
| + | |||
* Security | * Security | ||
| + | |||
* Launching | * Launching | ||
** Splash Screen | ** Splash Screen | ||
** fast workspace switching (currently we don't have any lifecycle events for location areas) | ** fast workspace switching (currently we don't have any lifecycle events for location areas) | ||
| + | |||
* Preferences | * Preferences | ||
** API fixes | ** API fixes | ||
| Line 33: | Line 41: | ||
** Work on an RFC for scopes as they seem generally useful. (particularly for searching) | ** Work on an RFC for scopes as they seem generally useful. (particularly for searching) | ||
** use common storage solution (described below) | ** use common storage solution (described below) | ||
| + | |||
* Version Tools - We have started working on some version verification tools to help people cope with the new plug-in (and feature) version number story. Super cool goal is to complete these tools and have them integrated into the SDK. Cool goal is to have them available as either part of the Core Tools or PDE Tools. | * Version Tools - We have started working on some version verification tools to help people cope with the new plug-in (and feature) version number story. Super cool goal is to complete these tools and have them integrated into the SDK. Cool goal is to have them available as either part of the Core Tools or PDE Tools. | ||
| + | |||
* Storage Service - So many different components have to serialize and they all roll their own storage solution whether it be using Properties files, ObjectOutputStreams, or another format. We should investigate a common storage service that multiple components can leverage. | * Storage Service - So many different components have to serialize and they all roll their own storage solution whether it be using Properties files, ObjectOutputStreams, or another format. We should investigate a common storage service that multiple components can leverage. | ||
| + | |||
* Services/Registry | * Services/Registry | ||
** Lazy Tracking | ** Lazy Tracking | ||
** Scalability issues for event dispatching and registry impl | ** Scalability issues for event dispatching and registry impl | ||
| + | |||
* Refactor Test Suites - we used to have one test plug-in for each plug-in in the SDK. Now that we have refactored the runtime we should also refactor the test suites to match the new bundle structure. | * Refactor Test Suites - we used to have one test plug-in for each plug-in in the SDK. Now that we have refactored the runtime we should also refactor the test suites to match the new bundle structure. | ||
Revision as of 14:21, 19 July 2006
Equinox Planning - 3.3
- Declarative Services
- Implementation
- Tooling
- Update Manager
- The update manager code ownership is migrating from Toronto to Ottawa. We need to keep on top of bug reports and current problems to ensure that nothing slips by for 3.2.1.
- We need to investigate refactoring the JarProcessor code. It was put into the Update bundles at the end of the 3.2 cycle but is more generally useful.
- JarProcessor - might be some more work here w.r.t. JAR signing and nested JARs
- Provisioning
- Prototype
- Investigate MEG
- How to deliver Eclipse?
- Small installer download?
- Dynamic web content that builds zip?
- PDE/Build
- Continue investigation into inter-operability with Maven
- Incremental building
- Component Model
- The programming model.
- Investigate Spring, DS, etc.
- We want to get people off the Platform class.
- Need to have something easy for people to use when they migrate their code.
- OSGi Framework (refactor/etc)
- Security
- Launching
- Splash Screen
- fast workspace switching (currently we don't have any lifecycle events for location areas)
- Preferences
- API fixes
- use everywhere - get people to adapt and get off the old JFace and Runtime prefs code
- should we create more scopes?
- Work on an RFC for scopes as they seem generally useful. (particularly for searching)
- use common storage solution (described below)
- Version Tools - We have started working on some version verification tools to help people cope with the new plug-in (and feature) version number story. Super cool goal is to complete these tools and have them integrated into the SDK. Cool goal is to have them available as either part of the Core Tools or PDE Tools.
- Storage Service - So many different components have to serialize and they all roll their own storage solution whether it be using Properties files, ObjectOutputStreams, or another format. We should investigate a common storage service that multiple components can leverage.
- Services/Registry
- Lazy Tracking
- Scalability issues for event dispatching and registry impl
- Refactor Test Suites - we used to have one test plug-in for each plug-in in the SDK. Now that we have refactored the runtime we should also refactor the test suites to match the new bundle structure.