You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Davide Giannella (JIRA)" <ji...@apache.org> on 2017/02/14 16:13:41 UTC

[jira] [Commented] (OAK-5437) Add a persistence-dependent namespace when running CLI commands

    [ https://issues.apache.org/jira/browse/OAK-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866038#comment-15866038 ] 

Davide Giannella commented on OAK-5437:
---------------------------------------

It's not clear to me if we're going to implement separate modules for each command and if so how we expect any user to leverage those.

> Add a persistence-dependent namespace when running CLI commands
> ---------------------------------------------------------------
>
>                 Key: OAK-5437
>                 URL: https://issues.apache.org/jira/browse/OAK-5437
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: run
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>              Labels: tooling
>             Fix For: 1.8
>
>
> Commands in oak-run currently live in a flat namespace. If a command is specific to only one implementation, it will leave along other implementation-specific commands without any means of distinguishing what belongs where.
> I would like to add a layer of indirection to the oak-run command line interface, so to parse commands in the following fashion:
> {noformat}
> oak-run segment debug /path/to/folder
> oak-run mongo debug mongodb://host:12345
> oak-run rdb debug jdbc:oracle:oci8:scott/tiger@myhost
> {noformat}
> In this scenario, oak-run would become a simple entry point that would delegate to implementation-specific command line utilities based on the first argument. In the previous example, {{segment}}, {{mongo}} and {{rdb}} would delegate to three different implementation specific CLI utilities. Each of these CLI utilities will understand the {{debug}} command and will collect command-line parameters as it sees fit.
> If the code for a command is so generic that can be reused from different commands, it can be parameterised and reused from different implementation-specific commands.
> The benefit of this approach is that we can start moving commands closer to the implementations. This approach would benefit oak-run as well, which is overloaded with many commands from many different implementations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)