hi thomas hey... we already have 2 modules for access control. one being just an optional implementation (module) that could be plugged additionally once we have support for composite authorization setup.
as far as i understood every single proposal and approach that was made over the last couple of years to modularise Oak, it always seemed perfectly reasonable to me. so far nobody was asking for ripping apart all of the oak-core layer s.str (the meat of the hamburger if you wish)... not mentioning that this wouldn't be possible right now due to the plugins mess we are having for the various JCR special areas. what we have been discussing over and over again and what everyone keeps proposing as a first step is: modularise based on the layers that we originally designed and agreed upon. having said that, i would like to remind you that we actually had that separation of layers in the original setup where the persistence layer was in a separate mk-api and mk-impl module... it's only due to political whatsoever that we found ourselves with abandoned mk-persistence modules and a new node store persistence model that is awkwardly 'hidden' in oak-core. so, my goal would be to restored the separation again now that we officially got rid of the abandoned code. i see to ways to get there: A) move the node store parts out of oak-core because they don't belong there as they are a different layer in our original - jcr (top-bread) - core (meat with all the validation) - persistence (bottom-bread, aka mk) design B) move the rest out of oak-core and 'redefine' the name 'oak-core' to be just the persistence (bottom-bread) but no longer representing the meat. from an architecture point of view A) looks like the desirable solution for me... B) looks really confusing to me but might be suited to address the concerns raised by those that fear that the node store implementations are too unstable and too heavily worked on. my concern with B) is that we will end up just doing what we currently try to avoid: heavily refactor and restructure the meat-layer and possibly ending up with way too many modules. as far as access control (and the other security related areas) is concerned, you can be assured that i will keep an eye on it... don't worry :-) kind regards angela On 06/08/15 12:25, "Thomas Mueller" <[email protected]> wrote: >Hi, > >> >>OTOH if one module does storage and indexing and access control and >>monitoring for example it's too much IMO, that should ideally be four >>modules. > >Again, what would be the benefit of having many Maven projects? Besides, I >don't think we could easily move all of access control to one Maven >project, because access control is a cross-cutting concern. Monitoring, I >don't think we do much of that right now. > >>in Sling we are only testing very few combinations, >>actually just one combination per release. > >Good to know! I still don't quite understand why you have many projects >then... what is the driver to create smaller and smaller projects? > >Regards, >Thomas >
