Maybe looking at this step by step would help. For example, start with the nodestore implementations and extract everything into separate modules that is necessary for this - i.e. an oak-store-api along with the impls. But keep other apis in oak-core in that first step, to limit the effort. (And try not renaming the API packages, as well as keeping them backwards compatible, i.e. no major version bump, if possible). See how that works out and if positive, continue with more.
Cheers, Alex Am 27. Okt. 2016, 03:48 -0700 schrieb Francesco Mari <[email protected]>: Something did happen: the first NodeStore implementation living in its own module was oak-segment-tar. We just decided to go back to the old model exactly because we didn't reach consensus about modularizing its upstream and downstream dependencies. 2016-10-27 12:22 GMT+02:00 Michael Marth <[email protected]>: fwiw: last year a concrete proposal was made that seemed to have consensus “Move NodeStore implementations into their own modules" http://markmail.org/message/6ylxk4twdi2lzfdz Agree that nothing happened - but I believe that this move might again find consenus On 27/10/16 10:49, "Francesco Mari" <[email protected]> wrote: We keep having this conversation regularly but nothing ever changes. As much as I would like to push the modularization effort forward, I recognize that the majority of the team is either not in favour or openly against it. I don't want to disrupt the way most of us are used to work. Michael Dürig already provided an extensive list of what we will be missing if we keep writing software the way we do, so I'm not going to repeat it. The most sensible thing to do is, in my humble opinion, accept the decision of the majority. 2016-10-27 11:05 GMT+02:00 Davide Giannella <[email protected]>: On 27/10/2016 08:53, Michael Dürig wrote: +1. It would also help re. backporting, continuous integration, releasing, testing, longevity, code reuse, maintainability, reducing technical debt, deploying, stability, etc, etc... While I can agree on the above, and the fact that now we have https://issues.apache.org/jira/browse/OAK-5007 in place, just for the sake or argument I would say that if we want to have any part of Oak with an independent release cycle we need to Have proper API packages that abstract things. Specially from oak-core As soon as we introduce a separate release cycle for a single module we have to look at a wider picture. What other modules are affected? Taking the example of segment-tar we saw that we need - oak-core-api (name can be changed) - independent releases of the oak tools: oak-run, oak-upgrade, ... - independent release cycle for parent/pom.xml - anything I'm missing? So if we want to go down that route than we have to do it properly and for good. Not half-way. Davide
