Hi all My preference is also with a higher degree of modularity. Compared to a monolithic application it is a trade-off that leads to both, higher complexity and higher flexibility. Provided we are willing to change and learn, I am sure we can easily manage the complexity. Numerous benefits of the extra flexibility have been mentioned in this thread before, so I won't repeat them.
As I understand it the Oak package structure was designed to facilitate modularity very early on. As Jukka wrote back in 2012: "[...] Ultimately such extra plugin components may well end up as separate Maven components, but until the related service interfaces and plugin boundaries are well defined it's better to keep all such code together and simply use Java package boundaries to separate them. That's the rationale behind the .oak.plugins package [...]"[0]. IMHO, now that the API boundaries are well defined (I hope), it would be great to finally move the structure of the code-base and release artifacts towards a more modular approach. Regards Julian [0] http://markmail.org/thread/cs34a637dr26xscj On Fri, Oct 28, 2016 at 8:29 AM, Francesco Mari <[email protected]> wrote: > 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 >> >>
