Hi all, I like the idea of a more modularized Oak. I agree with Michael's point of doing that gracefully, one step at a time, evaluate and iterate.
My opinion is that "having one/many Maven projects" is not the central point of discussion; I don't personally think having e.g. 13 poms instead of 10 would be much of a problem anyway but I think we should mainly decide if we want to support different deployment scenarios, e.g. we ship modules oak-x, oak-y and oak-z for deployment-a and modules oak-x, oak-w and oak-z for deployment-b. I don't think in this case we would have to commit to supporting all the theoretically possible deployment scenarios / bundle combinations. I generally agree with Angela's point regarding layers as they were originally thought (and we ended up with NS & co.) but not clearly separated, however I have very few insights on that portion of oak-core's code. What I would like to have with a more modularized Oak is that if, for example, I want to fix something in the query engine I can do that and only get the bundle containing the core search stuff (query engine / indexing / searching), not the whole oak-core that in the meantime (always for example) requires an updated semantic version of oak-commons APIs. Regarding Apache Lucene: it is modularized in the sense that you can use it by just depending on lucene-core, but in most cases you'll most probably have to use some Analyzer implementations (lucene-analyzers-commons), query extensions (lucene-queries and lucene-queryparser), specific codecs (lucene-codecs) etc. I think that brings a good example where separation of modules (Ant ones, no comments please [1]) is performed by allowing usage of lucene-core alone but in most cases you'll end up using some of the companion modules. Regards, Tommaso [1] : https://issues.apache.org/jira/browse/LUCENE-3167 2015-08-07 11:31 GMT+02:00 Thomas Mueller <[email protected]>: > Hi, > > I have nothing against modularization, I'm just against "modularization = > create many many Maven projects". I prefer modularization *within* one > project. Why can't we do that instead? > > >Ideally you have a ³root² project, e.g. > > > >/oak > > /security > > /api > > /implementationA > > /implementationB > > /core > > /persistence > > /.. > > That looks like a Java *package* structure to me. The Wikipedia article > you mentioned is not about Maven projects, but about modularity in general. > > Regards, > Thomas > >
