felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [jira] Resolved: (FELIX-2712) [SCR] Add Gogo command support
Date Thu, 23 Dec 2010 19:41:10 GMT

-> richard

On 12/23/10 13:20, Felix Meschberger (JIRA) wrote:
>       [ https://issues.apache.org/jira/browse/FELIX-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> Felix Meschberger resolved FELIX-2712.
> --------------------------------------
>      Resolution: Fixed
> Implemented the following Gogo commands in Rev. 1052345:
>    scr:list -- list all components (or components of a single bundle)
>    scr:info -- provide information for a component
>    scr:config -- SCR bundle configuration
>    scr:enable -- enable a component
>    scr:disable -- disable a component
> The Gogo command implementation uses the Java 5 Descriptor annotation to provide information
about the commands and parameters. Thus compilation setup is now special:
>   -- The Gogo command class is compiled with source/target 1.5
>   -- The rest is compiled with default setup (source/target 1.3)
> Therefore the bundle should perfectly deploy in a pre-Java 5 VM but without support for
the Gogo shell. In a Java 5 or higher VM the Gogo shell commands are available as expected.
>> [SCR] Add Gogo command support
>> ------------------------------
>>                  Key: FELIX-2712
>>                  URL: https://issues.apache.org/jira/browse/FELIX-2712
>>              Project: Felix
>>           Issue Type: New Feature
>>           Components: Declarative Services (SCR)
>>     Affects Versions:  scr-1.6.0
>>             Reporter: Richard S. Hall
>>             Assignee: Felix Meschberger
>>              Fix For: scr-1.6.2
>> Currently, SCR only provides an "scr" command for the old shell. It should also include
a Gogo command. A very simple approach would be to factor out the command implementation from
the Command interface, to eliminate the dependency on the Shell package. This object would
simply have a single method like public void scr(String[] args) that would do the current
processing. For Gogo you'd just register this object directly as the command with some service
properites, for Shell you'd wrap it in a Command.
>> A better approach would be to look at the OBR command for Gogo. In it, all OBR subcommands
(e.g., obr list) just become methods on the service object and accept the needed parameters.
The "obr" command becomes the command scope (in the service properties), so you can do "obr:list"
at the Gogo prompt or just "list" if there is no ambiguity. You could still wrap this object
in a Command to be compatible with Shell.
>> I'd recommend the second approach, since it allows you to leverage the Gogo annotations
to provide decent help for the command.

View raw message