When I think about a module, in the context of splitting oak-core in multiple modules, I think about an aggregation of code that can be separately compiled and distributed. With the tooling currently in place, this aggregation of code would be naturally represented by a Maven artifact.
Thomas, you are clearly not in favour of adding more Maven artifacts to Oak. How can we split oak-core in multiple modules without resorting to Maven? How can we enforce the requirements of separate compilation and individual distribution if we don't enclose a feature in a Maven artifact? 2015-08-07 14:18 GMT+02:00 Tommaso Teofili <tommaso.teof...@gmail.com>: > 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 <muel...@adobe.com>: > >> 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 >> >>
