[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] shell refactoring proposal

Krassi, 

This is great.  I've been wanting the console out of the framework for some time.  See Bug 169603.

Having a better, more functional console that has a better command UI structure would be a real bonus to many users.

As you observe, maintaining compatibility with the old way is essential both for contributors and users/doc.

I look forward to this work.  Thanks for coming forward.

Jeff


On 2010-03-30, at 6:20 PM, Semerdzhiev, Krasimir wrote:

Hi,
 
This is a short summary of an activity we believe fits to the current point in time and the direction of the project. Any input on that is highly appreciated.
 
Krassi
 
Introduction
We’d like to propose an incubation activity under the Eclipse Equinox umbrella which to result in a RFC147 compliant implementation of a shell in equinox. Furthermore it will result in better separation of the shell functionality from the main equinox framework, leaving only single required functional parts in the framework itself. In addition to that we aim at enhancing the standard set of commands for analyzing dependency and class loading issues within Equinox.
RCF147 is complementary to the just-released OSGi 4.2 specification and defines a standard way to implement and run commands on an OSGi 4.2 framework. Its main qualities span in the direction of ease of use, interactivity and ease of implementation and testing of provided commands.
 Scope
  • Provide an RFC147 compliant shell in equinox
  • Replace the current equinox console with a well componentized one
  • Maintain compatibility with the currently existing Equinox APIs for registering commands. Those are deeply embedded in the framework and must remain available.
  • Improve the experience of troubleshooting bundle issues when using Equinox. Focus on wiring, bundle resolution, class loading, etc. by providing additional commands with in-depth understanding of the framework implementation.
Timeframe
  • Aim for Eclipse 3.7 (2011) release and start there early in order to avoid intersection with other on-going development plans
  • Define a branch with a fork of Equinox sources in order to achieve easy merging back into the main line once development is completed and accepted
 
 
 
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev