[ https://issues.apache.org/jira/browse/OAK-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876055#comment-15876055 ]
Davide Giannella commented on OAK-5437: --------------------------------------- thanks for the clarifications. I see that while it's a nice thing on which I agree, it doesn't really relate to reducing the size of oak-run as we would eventually ship a über jar. It's orthogonal to the "slimming of oak run" epic. > 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)