[
https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878405#comment-15878405
]
Davide Giannella commented on OAK-3134:
---------------------------------------
[~tmueller]
bq. I wonder if somebody needs branch versions of oak-run.jar. I assume it's
not needed usually, so maybe we can disable the jar file from being built for
branches, or only generated with a specific profile?
As far as I remember the branch in oak-run are needed as we have different
repository constructions and different segments format (for example). I can be
wrong; not been looking at that code for a while. So short answer is: we need
the branches of oak-run, at least for the "operational tasks".
[~anchela]
{quote}
if we start looking at ways to move the benchmarks out of oak-run I would
rather opt for an approach as mentioned by Francesco Mari on the mailing list.
IMHO the benchmarks should live with the code they are intended to benchmark
and not in a separate module. this would also solve the question wrt different
branches/versions of the benchmarks.
just moving them to a new oak-benchmark module without addressing the
underlying issue doesn't make sense to me...
{quote}
The approach [~frm] was suggesting in OAK-5437 was then going to be delivered
as an embedding/über jar in the form of oak-run. therefore it won't address the
size issue (if not making it worse) by moving the benchmarks close to the
implementation.
By simply splitting out the benchmarks off oak-run as we don't need to embed
them for production usage we could save quite some space by previous
investigations.
> 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)
