[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] shell refactoring proposal
- From: Alin Dreghiciu <adreghiciu@xxxxxxxxx>
- Date: Wed, 31 Mar 2010 03:52:34 +0300
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Kgi+Llaravts+vlzulRDZ2TE2l3fMXNHwL0TKGrVpwOt5c+ysY6SiRN4UKkrknVHgL SHtI4xWjs+EWWys1ATba693FNLYCwx4jkC2T7WWE75ESP4jUjHhJM5Xaxm/ctoEC/2y5 BIH/CYavLaKju1dMrMu3DwPF3aslUKZuGAX6A=
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.
On Wed, Mar 31, 2010 at 1:20 AM, Semerdzhiev, Krasimir
> 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
> 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.
> 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
> 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
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
http://www.qi4j.org - New Energy for Java - Domain Driven Development.