Looking to see if there's a best practice defined anywhere. The newer archetypes use the concept of the "core" maven project for all the java related code that typically goes in a bundle. I have a codebase that's been in use since the 5.x days which consists of multiple custom bundles with varying level of dependencies. I want to help move it into the newer archetypes and follow newer best practices around structure. Even though managing the dependencies can be a challenge it does offer flexibility to turn smaller features off i.e. turning off events when doing large content updates or restarting a troublesome feature, etc. and keep features logically separated. My concern with a single large core bundle is that its a larger codebase for a larger site is having this big monolith of a jar file.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @sboyleuf!
There is no strict general ruling on when to split functionality into different bundles or when to keep everything together in one.
The latest AEM Maven archetype comes with a single core bundle because that's how you usually start a green field project. It gives you a quick and easy start for a new project and comes with everything that needed.
From my practical experience, a lot of projects are totally fine with having all their Java functionality in one bundle as their development is handled by a single team and deployment done through a single JCR package that contains everything. When your project grows (or you start with a project that's designed to be big) you may come to a point where you find benefits by splitting your code into different bundles and/or packages.
Reasons to split could be:
This is not an exclusive list and there can be other reasons. Also most of these reason don't make it mandatory to work with different bundles (the release cycle one probably, though).
Hope that helps!
Hi @sboyleuf!
There is no strict general ruling on when to split functionality into different bundles or when to keep everything together in one.
The latest AEM Maven archetype comes with a single core bundle because that's how you usually start a green field project. It gives you a quick and easy start for a new project and comes with everything that needed.
From my practical experience, a lot of projects are totally fine with having all their Java functionality in one bundle as their development is handled by a single team and deployment done through a single JCR package that contains everything. When your project grows (or you start with a project that's designed to be big) you may come to a point where you find benefits by splitting your code into different bundles and/or packages.
Reasons to split could be:
This is not an exclusive list and there can be other reasons. Also most of these reason don't make it mandatory to work with different bundles (the release cycle one probably, though).
Hope that helps!
@sboyleuf It just depends on how many different projects/websites/applications you host and how would you like to scale up in future.
End of day, all bundles has to be embed in either all pom.xml or your individual tenant ui.apps to make it into a code build and deployment pipelines.
you can refer my project model below and also some helpful links:-
https://aem.design/blog/2020/01/12/aem-framework-for-multi-tenant-environments
https://dev.to/anfibiacreativa/integrating-a-modern-frontend-in-a-multi-tenant-aem-project-2l20
Thanks guys. You confirmed what I suspected. I just wanted to make sure there wasn't some official guidance esp. with alot of the changes needed to support working on Cloud Service.
Views
Likes
Replies
Views
Likes
Replies