When to use multiple bundles vs single core | Community
Skip to main content
Level 2
May 11, 2021
Solved

When to use multiple bundles vs single core

  • May 11, 2021
  • 3 replies
  • 1755 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MarkusBullaAdobe

Hi @irishgator!

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!

3 replies

MarkusBullaAdobe
Adobe Employee
MarkusBullaAdobeAdobe EmployeeAccepted solution
Adobe Employee
May 12, 2021

Hi @irishgator!

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!

Shashi_Mulugu
Community Advisor
Community Advisor
May 12, 2021

@irishgator 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-multi-module-project-with-multi/qaq-p/382013

 

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

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

 

Level 2
May 12, 2021

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.