Hi 2016-10-27 19:08 GMT+02:00 Alexander Klimetschek <[email protected]>: > Maybe looking at this step by step would help.
The oak-segment-tar bundle was supposed to be the first step. >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). This didn't happen because of lack of consensus. See my previous answer to Michael Marth. >See how that works out and if positive, continue with more. The reaction to the modularization effort was not positive, so oak-segment-tar backed up. > > 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 > >
