As much as I like the proposal of slimming down oak-run, I think that dividing oak-run in oak-operations and oak-development is the wrong way to go. This kind of division is horizontal, since commands pertaining to different persistence backends are grouped together according to their roles. This division will not solve the problem of feature bloat. These two modules will grow over time in the same way that oak-run did.
I'm more in favour of a vertical separation of oak-run. I explained part of this idea in OAK-5437. I think it's more effective to split oak-run in vertical slices, where each slice pertains to a persistence layer (segment, mongo, etc.) or a well defined functional area (indexing, security, etc.). This kind of separation would bring the CLI code close to the main code they are working with. Changes in the main code are more easily reflected in the CLI code, and the other way around. It would also be easier to figure out which individual or group of individuals is actively maintaining a certain piece of code. 2017-02-10 9:44 GMT+01:00 Angela Schreiber <[email protected]>: > hi davide > > could you elaborate a bit on your proposal? from the names (oak-operations > and oak-development) it's not clear to me what code would go into which > module... also i am not sure about deleting oak-run. for the sake of > limiting impact (also when it comes to the backport you mention later on) > i would rather suggest to move out code that doesn't belong there and keep > stuff that more naturally fits into 'run': so, only one additional module > and no deletion. > > as far as backporting to all branches is concerned: that's for sure not > feasible for the benchmarks i have been putting into oak-run when > introducing new features and improvements. > > kind regards > angela > > On 09/02/17 20:28, "Davide Giannella" <[email protected]> wrote: > >>hello team, >> >>while having a bit of time I resumed the topic grouped in the epic >>https://issues.apache.org/jira/browse/OAK-5599. >> >>Part of the discussion we already had in the past 1 or two years is that >>oak-run is big and begin to be a challenge during releases and the fact >>that we could split development functionalities from production tooling >>would allow us to remove quite a bunch of libraries from the jar >>deployed on mvn for production tooling and will leave the development >>one not deployed. >> >>Main scratching I have now is: assuming we proceed what about backports? >>So i thought the following: >> >>- main goal: create oak-operations and oak-development modules. >>Eventaully delete oak-run. >>- backport these on all the branches. Up to what version? Can we blindly >>backport all of the stuff? >>- what are the differences nowadays in oak-run between branches? >>Repository construction? others? >> >>Thoughts? >> >>Cheers >>Davide >
