I also agree that existing impls should be considered. My hope is that the end result is at least as powerful as the current state of the art. If using existing stuff or working with those teams is the way to go then +1. Having said that, if this team is keen on creating and maintaining a new impl, that has benefits as well.
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
<graycol.gif>Alin Dreghiciu ---03/30/2010 07:52:48 PM---I do not want to start a flame war here but just out of curiosity: why
<ecblank.gif>
From: | <ecblank.gif>
Alin Dreghiciu <adreghiciu@xxxxxxxxx> |
<ecblank.gif>
To: | <ecblank.gif>
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: | <ecblank.gif>
03/30/2010 07:52 PM |
<ecblank.gif>
Subject: | <ecblank.gif>
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.semerdzhiev@xxxxxxx> 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
>
>
--
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|
