Cool! -> 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.
