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" <dav...@apache.org> 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
