You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2008/10/16 08:42:24 UTC
[DISCUSS] Upgrade ServiceMix Kernel to latest GShell.
I'm currently working on upgrading ServiceMix Kernel to the latest gshell trunk.
GShell has undergone some major refactoring and now uses spring
instead of plexus for its configuration.
This means that all the crapy code from our gshell-core module goes
away, but there are a few things I'd like to discuss.
The first thing is that there is some incompatibility between the
version we use and the trunk for defining commands.
I've recreated locally OsgiCommandSupport class which does most of the
work, so mostly the code is easy to migrate:
* remove the annotation on the command
* replace the @Requirement annotation by spring @Autowired annotation
* change a few packages when they have been moved in gshell
* the return value SUCCESS / FAILED are now enums and thus need to
be changed to Result.SUCCESS / Result.FAILED
So this is quite easy.
The configuration is now really different, but much easier too.
Instead of having the following definitions for each command:
<bean id="bundle-level"
class="org.apache.geronimo.gshell.osgi.BundleLevel" />
<osgi:service ref="bundle-level"
interface="org.apache.geronimo.gshell.command.Command">
<osgi:service-properties>
<entry key="shell" value="osgi"/>
<entry key="name" value="bundle-level"/>
</osgi:service-properties>
</osgi:service>
You can now write:
<import resource="classpath:org/apache/servicemix/kernel/gshell/core/commands.xml"
/>
<gshell:command-bundle>
<gshell:command name="osgi/bundle-level">
<gshell:action
class="org.apache.servicemix.kernel.gshell.osgi.BundleLevel" />
</gshell:command>
... other commands here ...
</gshell:command-bundle>
The second point is that gshell is natively written to organize the
commands and access them as if they were on a file system.
So instead of:
osgi install xxx
you would write:
osgi/install xxx
The nice thing is that the completion now works which helps a lot when
writing commands.
So the question is: should be try to keep the previous command syntax
and hack gshell to follow what we want, or should we just switch to
the new syntax ?
I'm currently working locally and I have not updated the branch I
created some time ago, but if someone wants to have a look at the
code, I can commit / upload it somewhere.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Upgrade ServiceMix Kernel to latest GShell.
Posted by Gert Vanthienen <ge...@skynet.be>.
Guillaume,
I think it makes sense to upgrade to the latest GShell now. Right now,
there aren't that many people using ServiceMix so the impact from the
syntax change isn't a problem yet. For new users, the command
completion feature is a big plus.
And from a development perspective, we are better off staying current
with GShell instead of having to hack GShell all the time to add
features we want.
Regards,
Gert
Guillaume Nodet schreef:
> I'm currently working on upgrading ServiceMix Kernel to the latest gshell trunk.
> GShell has undergone some major refactoring and now uses spring
> instead of plexus for its configuration.
> This means that all the crapy code from our gshell-core module goes
> away, but there are a few things I'd like to discuss.
>
> The first thing is that there is some incompatibility between the
> version we use and the trunk for defining commands.
> I've recreated locally OsgiCommandSupport class which does most of the
> work, so mostly the code is easy to migrate:
> * remove the annotation on the command
> * replace the @Requirement annotation by spring @Autowired annotation
> * change a few packages when they have been moved in gshell
> * the return value SUCCESS / FAILED are now enums and thus need to
> be changed to Result.SUCCESS / Result.FAILED
> So this is quite easy.
> The configuration is now really different, but much easier too.
> Instead of having the following definitions for each command:
>
> <bean id="bundle-level"
> class="org.apache.geronimo.gshell.osgi.BundleLevel" />
> <osgi:service ref="bundle-level"
> interface="org.apache.geronimo.gshell.command.Command">
> <osgi:service-properties>
> <entry key="shell" value="osgi"/>
> <entry key="name" value="bundle-level"/>
> </osgi:service-properties>
> </osgi:service>
>
> You can now write:
>
> <import resource="classpath:org/apache/servicemix/kernel/gshell/core/commands.xml"
> />
>
> <gshell:command-bundle>
> <gshell:command name="osgi/bundle-level">
> <gshell:action
> class="org.apache.servicemix.kernel.gshell.osgi.BundleLevel" />
> </gshell:command>
> ... other commands here ...
> </gshell:command-bundle>
>
> The second point is that gshell is natively written to organize the
> commands and access them as if they were on a file system.
> So instead of:
> osgi install xxx
> you would write:
> osgi/install xxx
> The nice thing is that the completion now works which helps a lot when
> writing commands.
> So the question is: should be try to keep the previous command syntax
> and hack gshell to follow what we want, or should we just switch to
> the new syntax ?
>
> I'm currently working locally and I have not updated the branch I
> created some time ago, but if someone wants to have a look at the
> code, I can commit / upload it somewhere.
>
>
Re: [DISCUSS] Upgrade ServiceMix Kernel to latest GShell.
Posted by Freeman Fang <fr...@gmail.com>.
Hi Guillaume,
Use the new gshell syntax is better for me, the auto-completion feature
is useful for end user.
Cheers
Freeman
Guillaume Nodet wrote:
> I'm currently working on upgrading ServiceMix Kernel to the latest gshell trunk.
> GShell has undergone some major refactoring and now uses spring
> instead of plexus for its configuration.
> This means that all the crapy code from our gshell-core module goes
> away, but there are a few things I'd like to discuss.
>
> The first thing is that there is some incompatibility between the
> version we use and the trunk for defining commands.
> I've recreated locally OsgiCommandSupport class which does most of the
> work, so mostly the code is easy to migrate:
> * remove the annotation on the command
> * replace the @Requirement annotation by spring @Autowired annotation
> * change a few packages when they have been moved in gshell
> * the return value SUCCESS / FAILED are now enums and thus need to
> be changed to Result.SUCCESS / Result.FAILED
> So this is quite easy.
> The configuration is now really different, but much easier too.
> Instead of having the following definitions for each command:
>
> <bean id="bundle-level"
> class="org.apache.geronimo.gshell.osgi.BundleLevel" />
> <osgi:service ref="bundle-level"
> interface="org.apache.geronimo.gshell.command.Command">
> <osgi:service-properties>
> <entry key="shell" value="osgi"/>
> <entry key="name" value="bundle-level"/>
> </osgi:service-properties>
> </osgi:service>
>
> You can now write:
>
> <import resource="classpath:org/apache/servicemix/kernel/gshell/core/commands.xml"
> />
>
> <gshell:command-bundle>
> <gshell:command name="osgi/bundle-level">
> <gshell:action
> class="org.apache.servicemix.kernel.gshell.osgi.BundleLevel" />
> </gshell:command>
> ... other commands here ...
> </gshell:command-bundle>
>
> The second point is that gshell is natively written to organize the
> commands and access them as if they were on a file system.
> So instead of:
> osgi install xxx
> you would write:
> osgi/install xxx
> The nice thing is that the completion now works which helps a lot when
> writing commands.
> So the question is: should be try to keep the previous command syntax
> and hack gshell to follow what we want, or should we just switch to
> the new syntax ?
>
> I'm currently working locally and I have not updated the branch I
> created some time ago, but if someone wants to have a look at the
> code, I can commit / upload it somewhere.
>
>
Re: [DISCUSS] Upgrade ServiceMix Kernel to latest GShell.
Posted by Guillaume Nodet <gn...@gmail.com>.
It's still typing the shell name.
On Thu, Oct 16, 2008 at 9:34 AM, Chris Custine <cc...@apache.org> wrote:
> Hi Guillaume,
> This all sounds good, and I like the new command syntax much better anyway
> ;-) So to change to a sub shell would the command be "cd osgi" or do you
> still just type the shell name?
>
> Chris
>
> --
> Chris Custine
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Thu, Oct 16, 2008 at 12:42 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> I'm currently working on upgrading ServiceMix Kernel to the latest gshell
>> trunk.
>> GShell has undergone some major refactoring and now uses spring
>> instead of plexus for its configuration.
>> This means that all the crapy code from our gshell-core module goes
>> away, but there are a few things I'd like to discuss.
>>
>> The first thing is that there is some incompatibility between the
>> version we use and the trunk for defining commands.
>> I've recreated locally OsgiCommandSupport class which does most of the
>> work, so mostly the code is easy to migrate:
>> * remove the annotation on the command
>> * replace the @Requirement annotation by spring @Autowired annotation
>> * change a few packages when they have been moved in gshell
>> * the return value SUCCESS / FAILED are now enums and thus need to
>> be changed to Result.SUCCESS / Result.FAILED
>> So this is quite easy.
>> The configuration is now really different, but much easier too.
>> Instead of having the following definitions for each command:
>>
>> <bean id="bundle-level"
>> class="org.apache.geronimo.gshell.osgi.BundleLevel" />
>> <osgi:service ref="bundle-level"
>> interface="org.apache.geronimo.gshell.command.Command">
>> <osgi:service-properties>
>> <entry key="shell" value="osgi"/>
>> <entry key="name" value="bundle-level"/>
>> </osgi:service-properties>
>> </osgi:service>
>>
>> You can now write:
>>
>> <import
>> resource="classpath:org/apache/servicemix/kernel/gshell/core/commands.xml"
>> />
>>
>> <gshell:command-bundle>
>> <gshell:command name="osgi/bundle-level">
>> <gshell:action
>> class="org.apache.servicemix.kernel.gshell.osgi.BundleLevel" />
>> </gshell:command>
>> ... other commands here ...
>> </gshell:command-bundle>
>>
>> The second point is that gshell is natively written to organize the
>> commands and access them as if they were on a file system.
>> So instead of:
>> osgi install xxx
>> you would write:
>> osgi/install xxx
>> The nice thing is that the completion now works which helps a lot when
>> writing commands.
>> So the question is: should be try to keep the previous command syntax
>> and hack gshell to follow what we want, or should we just switch to
>> the new syntax ?
>>
>> I'm currently working locally and I have not updated the branch I
>> created some time ago, but if someone wants to have a look at the
>> code, I can commit / upload it somewhere.
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Upgrade ServiceMix Kernel to latest GShell.
Posted by Chris Custine <cc...@apache.org>.
Hi Guillaume,
This all sounds good, and I like the new command syntax much better anyway
;-) So to change to a sub shell would the command be "cd osgi" or do you
still just type the shell name?
Chris
--
Chris Custine
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
On Thu, Oct 16, 2008 at 12:42 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm currently working on upgrading ServiceMix Kernel to the latest gshell
> trunk.
> GShell has undergone some major refactoring and now uses spring
> instead of plexus for its configuration.
> This means that all the crapy code from our gshell-core module goes
> away, but there are a few things I'd like to discuss.
>
> The first thing is that there is some incompatibility between the
> version we use and the trunk for defining commands.
> I've recreated locally OsgiCommandSupport class which does most of the
> work, so mostly the code is easy to migrate:
> * remove the annotation on the command
> * replace the @Requirement annotation by spring @Autowired annotation
> * change a few packages when they have been moved in gshell
> * the return value SUCCESS / FAILED are now enums and thus need to
> be changed to Result.SUCCESS / Result.FAILED
> So this is quite easy.
> The configuration is now really different, but much easier too.
> Instead of having the following definitions for each command:
>
> <bean id="bundle-level"
> class="org.apache.geronimo.gshell.osgi.BundleLevel" />
> <osgi:service ref="bundle-level"
> interface="org.apache.geronimo.gshell.command.Command">
> <osgi:service-properties>
> <entry key="shell" value="osgi"/>
> <entry key="name" value="bundle-level"/>
> </osgi:service-properties>
> </osgi:service>
>
> You can now write:
>
> <import
> resource="classpath:org/apache/servicemix/kernel/gshell/core/commands.xml"
> />
>
> <gshell:command-bundle>
> <gshell:command name="osgi/bundle-level">
> <gshell:action
> class="org.apache.servicemix.kernel.gshell.osgi.BundleLevel" />
> </gshell:command>
> ... other commands here ...
> </gshell:command-bundle>
>
> The second point is that gshell is natively written to organize the
> commands and access them as if they were on a file system.
> So instead of:
> osgi install xxx
> you would write:
> osgi/install xxx
> The nice thing is that the completion now works which helps a lot when
> writing commands.
> So the question is: should be try to keep the previous command syntax
> and hack gshell to follow what we want, or should we just switch to
> the new syntax ?
>
> I'm currently working locally and I have not updated the branch I
> created some time ago, but if someone wants to have a look at the
> code, I can commit / upload it somewhere.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>