Hi, What about moving benchmarks to a new module oak-benchmark? I'm not sure if it's feasible, and not sure if it would reduce the size a lot. But it is easy to understand, where oak-operations and oak-development is quite fuzzy.
Regards, Thomas On 10/02/17 10:09, "Francesco Mari" <[email protected]> wrote: >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 >>
