Expand my Community achievements bar.

SOLVED

When to use multiple bundles vs single core

Avatar

Level 2

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.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

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:

  • Varying release cycles for different parts of your application
  • Dedicated teams working on different parts of the code base
  • A growing code base where you feel that certain parts should be handled separately.
  • Different technologies, libraries or functionalities that you want to separate.

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!

View solution in original post

3 Replies

Avatar

Correct answer by
Employee Advisor

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:

  • Varying release cycles for different parts of your application
  • Dedicated teams working on different parts of the code base
  • A growing code base where you feel that certain parts should be handled separately.
  • Different technologies, libraries or functionalities that you want to separate.

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!

Avatar

Community Advisor

@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://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-archetype-23-24-maven-...

 

https://levelup.gitconnected.com/aem-multitenancy-running-multiple-websites-on-a-single-aem-environm...

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

 

Avatar

Level 2

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.