I agree that part of this work should be to evaluate the current implementations of the proposed standard (it is not currently an official OSGi specification) to see if they can meet our needs. A large part of this work is to extract out the console from the Equinox framework but still make it really simple to get the console up and running.
java -jar equinox.jar -console
Ideally that should just continue to work. With that said I think it is
still valuable to provide a separate implementation from GoGo simply from a
proposed specification point of view. Peter wrote the RFC and the initial
implementation. I think it would be good to get another implementation of
the core console going to gain confidence in the proposed specification and
help push it through to a final version in the next version of the OSGi
compendium specification.
Tom
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Alin Dreghiciu <adreghi...@gmail.com>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Equinox development mailing list <equinox-dev@eclipse.org>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|03/30/2010 07:52 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [equinox-dev] shell refactoring proposal
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
I do not want to start a flame war here but just out of curiosity: why
do you want to develop an equinox specific implementation of RFC147
whne there are already implementation out there like:
Apache Felix GoGo - This si started from the code Peter Kriens
developed as part of RFP
Apache Karaf - this builds in top of GoGo and Gshell and has all sort
of nice features like auto completion, commands discovery, all sorts
of RDF compatible commands implementations...
Paremus Posh (here I do not know the licensing)
OPS4J Pax Shell (stopped development for same reasons as presented here)
and all of this can be run in top of equinox. For gogo and karaf shell
I have tried them as can be seen here: http://is.gd/b7omD
Now, I do agree and like the idea of extracting the console out of
framework and I suppose that there are some backwards compatibility
issues to be addressed but I fully believe that this still does not
trigger another implementation.
What I think the focus should be, as you mention, is create value
added commands that may be or not equinox specific.
My 2c, hoping that nobody is offended.
Alin Dreghiciu
On Wed, Mar 31, 2010 at 1:20 AM, Semerdzhiev, Krasimir
<krasimir.semerdzh...@sap.com> 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@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
--
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.wordpress.com
http://sonatype.com - Sonatype - The Maven Company
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
