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] [Commented] (OAK-3134) Identify functionality offered by oak-run
Date Thu, 16 Feb 2017 14:53:41 GMT

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

Michael Dürig commented on OAK-3134:
------------------------------------

I think there is two different aspects here:

1. Feature bloat and maintainability of {{oak-run}}: moving the various tools closer to the
implementations makes them simpler to implement, maintain and test. {{oak-run}} would simply
become an unified entry point and an assembly for distribution. See [~frm]'s post on oak-dev
\[1] and OAK-5437. 

2. Separating different types of functionality. Independently of how we call it we should
ask ourselves for each particular piece of tooling: Is is safe to use? Is it stable enough?
Do we tests it? Is it well documented? Is it useful for a user of Oak or a product build on
top of it? Only if we can answer these questions with yes should the tool be publicly recommended.
In other cases the tool should either not be distributed in the same assembly or come with
a disclaimer of some sort. The former approach is AFAIU what [~edivad] intents with the separation
into distinct modules "operation" and "development". The latter is more like what Git is doing
with its separation into "Porcelain" and "Plumbing". 

\[1] http://markmail.org/message/6ypw57uqowzrxfli

> Identify functionality offered by oak-run
> -----------------------------------------
>
>                 Key: OAK-3134
>                 URL: https://issues.apache.org/jira/browse/OAK-3134
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: run
>            Reporter: Davide Giannella
>            Assignee: Davide Giannella
>
> oak-run reached the size of 50MB+ and offers indeed various functionalities that could
be moved to their own module.
> This ticket is about to identify what oak-run currently offers and what/if could be split.
> ML thread: http://markmail.org/thread/w34bphrk57l7pkaz
> || Functionality || Package || Module ||
> | Backup | | oak-operations|
> | Check | | oak-operations|
> | Checkpoints | | oak-operations|
> | Compact | | oak-operations|
> | Debug | | oak-operations|
> | Explore | |oak-development |
> | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console
| oak-operations|
> | Primary | | oak-development|
> | Recovery | | oak-operations|
> | Repair | | oak-operations|
> | Restore | | oak-operations|
> | Server | | oak-development|
> | Standby | | oak-development|
> | Upgrade | | oak-upgrade|
> | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development |
> | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development|
> | DataStoreCacheUpgrade | | oak-operations |
> | DataStoreCheck | | oak-operations |
> | Garbage | | oak-operations |
> | tarmkdiff | | oak-operations |
> | tarmkrecovery | | oak-operations |
> | graph | | oak-development |
> | history | | oak-operations |
> | index | | oak-operations |
> | persistentcache | | oak-operations |
> | resetclusterid | | oak-operations |
> | threaddump | | oak-development |
> | tika | | oak-operations |
> Modules left after the actions:
> **oak-development**
> Used to group and execute all the tools used during development.
> _deployed to maven:_ No.
> **oak-operations**
> Used to group and execute all the tools used normally in production environment for tasks
like maintenance & C.
> _deployed to maven:_ Yes.
> **oak-run**
> Will group what's left after the split.
> _deployed to maven:_ No.
> **oak-upgrade**
> Will group tools for upgrading/migrating from one repo/version to another
> _deployed to maven:_ yes.



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

Mime
View raw message