[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=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)
[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=15874449#comment-15874449
]
Francesco Mari commented on OAK-5437:
-
[~edivad], the idea is to keep CLI code close to the module where that code
belongs. In example, the code for the {{compact}} command should live close to
the code implementing the Segment Store, either in the same module or in a
module that is built together with the Segment Store. We would distribute one
or more collections of command line utilities, one per persistence
implementation. We could still provide a über distribution of command line
utilities (similar to oak-run), but we would "namespace" the commands by the
persistence implementation name they belong to.
> 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)
[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=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)
