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 >>> >>>
