Ideally you have a “root” project, e.g.
/oak
/security
/api
/implementationA
/implementationB
/core
/persistence
/..
Apache Aries has for example a pretty nicely structured hierarchical Maven
set-up. You can still build all of it starting on top..
In the end smaller modules help theoretically with
- Risk assessment for deployments
- Test planing
- Rollouts
- Cleaner architecture
- Separation of concern
- Separation of necessary dependencies from unnecessary dependencies
- Customer specific implementation of API
https://en.wikipedia.org/wiki/Modular_programming#Key_aspects
On 06/08/15 15:28, "Thomas Mueller" <[email protected]> wrote:
>Hi,
>
>> we already have 2 modules for access control
>
>That's fine... What I meant is, we shouldn't try to move oak-core
>org.apache.jackrabbit.oak.security.** plus
>org.apache.jackrabbit.oak.spi.security.** to new Maven projects. Or should
>we?
>
>> jcr (top-bread)
>> core (meat with all the validation)
> > persistence
>
>
>I still don't see a reason why we should have "persistence" separate Maven
>project(s). What would it bring us? We anyway don't plan to combine
>"persistence 1.2" with "core 1.0", because we don't have testing in place.
>
>On the other side, I see many complications. We have datastore and
>blobstore, Mongo persistence from the RDB persistence are not completely
>independent (and they should not be), we have persisence wrappers
>(TimingDocumentStoreWrapper for example), caching (including persistent
>cache), discovery lite... If we want to create separate Maven projects for
>each of those (plus API projects, plus "commons" projects), we would
>easily have more Maven projects than we have Java packages right now.
>Sure, you could say we just create one "persistence" Maven project... but
>what for, really?
>
>Regards,
>Thomas
>
