You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2014/02/21 10:21:22 UTC

[jira] [Updated] (KARAF-2772) Separate command api and support classes from shell

     [ https://issues.apache.org/jira/browse/KARAF-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider updated KARAF-2772:
---------------------------------------

    Description: 
Like discussed on irc we would like to make karaf commands more reusable outside karaf.

The goal is to run karaf commands without the karaf shell.

So we need to split the shell project in two parts:
- command-api (proposed name)
  contains command API + supporting classes like AbstractCommand which are necessary to run Action classes
- shell.console impls

The command-api bundle should only depend on the OSGi APIs and gogo to make it lightweight. So projects implementing commands can do this while having minimal compile time dependencies to karaf.

I already took a peek into the shell to see how difficult this is. I found very few problematic classes.

One is ConsoleFactory which depends on jline and several exceptions which use jansi. 
-> I propose we move this to a new package console.factory. This package then needs to remain in shell.console

The other is NamespaceHandler
-> The blueprint NamespaceHandler can not go to the API bundle as it depends on aries. So for now we could move it to console.commands.blueprint.impl or similar and leave it in shell.console



  was:
Like discussed on irc we would like to make karaf commands more reusable outside karaf.

The goal is to run karaf commands without the karaf shell.

So we need to split the shell project in two parts:
- command-api (proposed name)
  contains command API + supporting classes like AbstractCommand which are necessary to run Action classes
- shell 

The command-api bundle should only depend on the OSGi APIs to make it lightweight.

I already took a peek into the shell to see how difficult this is. I found very few problematic classes.

One is ConsoleFactory which depends on jline and several exceptions which use jansi. 

ConsoleFactory can be easily moved
For the exceptions I propose to only store the parts and do the formatting in the shell bundle.



> Separate command api and support classes from shell
> ---------------------------------------------------
>
>                 Key: KARAF-2772
>                 URL: https://issues.apache.org/jira/browse/KARAF-2772
>             Project: Karaf
>          Issue Type: Improvement
>          Components: karaf-shell
>    Affects Versions: 3.0.0
>            Reporter: Christian Schneider
>            Assignee: Christian Schneider
>             Fix For: 3.1.0
>
>
> Like discussed on irc we would like to make karaf commands more reusable outside karaf.
> The goal is to run karaf commands without the karaf shell.
> So we need to split the shell project in two parts:
> - command-api (proposed name)
>   contains command API + supporting classes like AbstractCommand which are necessary to run Action classes
> - shell.console impls
> The command-api bundle should only depend on the OSGi APIs and gogo to make it lightweight. So projects implementing commands can do this while having minimal compile time dependencies to karaf.
> I already took a peek into the shell to see how difficult this is. I found very few problematic classes.
> One is ConsoleFactory which depends on jline and several exceptions which use jansi. 
> -> I propose we move this to a new package console.factory. This package then needs to remain in shell.console
> The other is NamespaceHandler
> -> The blueprint NamespaceHandler can not go to the API bundle as it depends on aries. So for now we could move it to console.commands.blueprint.impl or similar and leave it in shell.console



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)