jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Updated] (OAK-5437) Add a persistence-dependent namespace when running CLI commands
Date Wed, 06 Dec 2017 10:20:00 GMT

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

Michael Dürig updated OAK-5437:
    Fix Version/s:     (was: 1.8)

> 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
> 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

View raw message