Hi All,
We have a one website i.e SITE-A setup already in place with maven project code base in AEM as cloud service.
Now requirement is to reuse the same components from the code base for SITE-B and also possibility to create SITE-B specific components with new template for SITE-B
Questions -
what should be the right approach to create the correct maven project code structure to include SITE-B template, reuse existing component and few new one one will be create for SITE-B
How the dispatcher configuration will be separate for Site-B
@arunpatidar @konstantyn_diachenko @Jörg_Hoh
Solved! Go to Solution.
Views
Replies
Total Likes
If you have different teams managing each site code base and/or you want to manage separately the release strategy and/or you must run independent gitflows, then I think having unique maven modules would be fit. And everything that is common from site-a would be moved to a commons module and extended from there in case customizations are required. Of course, this is doable when you have let's say a low number of sites, maybe up to 5 (it is not an exact rule).
The other approach, by keeping only one module, but create folder inside to differentiate the codebase for each site, in my view would be same thing in terms of amount of files to manage, but only more complicated and prone to errors. I would still keep things separately and cleaner.
If you think that you will have to support lots and lots of sites, each with mostly same components and services but just slightly different, then you might think of making the code smarter. Implement the logic to support different behaviors for different sites (or group of sites), keeping the number of components/services/templates etc as lower as you can manage them.
There is always a tradeoff between how flexible is your end solution and how maintainable it is.
Consider also using techniques like components proxing and components versioning.
There can be multiple ways to achieve this.
In our current project we have only one ui.apps, ui.content, core module and we segregated the code and content within those modules.
@arunpatidar one ui.apps, ui.content, core module means by default you might have the structure for the very first website and later within each module you have manually created the other website structure ?
please note , still we have only one git repo to use for both site-a and siteb
i.e ui.apps
site-a
ui.apps
then later for another site say site-b , manually new structure was created ?
site-b
ui.apps
Views
Replies
Total Likes
I meant
ui.apps/src/main/content/jcr_root/apps/site-a/components
ui.apps/src/main/content/jcr_root/apps/site-b/components
@arunpatidar thanks for responding,
how about core module . will it will like below structure ? incase site-b have its own new component and services and impl to be called. also incase both site-a and site-b wants to consume any common services , servlet then any structure changes needed ? any chnages in pom.xml ?
\core\src\main\java\com\site-a
\core\src\main\java\com\site-b
Views
Replies
Total Likes
Yes, you can also create different java package(\core\src\main\java\com\site-b) for site-b, if changes are specific to site-b.
Views
Replies
Total Likes
thanks @arunpatidar - incase site-b component have to reuse one of the site-a core package then site-b component sightly can call site-a core sling models and its methods ..correct ?
Views
Replies
Total Likes
yes,you can directly use it, since the code for site-a and site-b are in the same bundle
Hi.
I will not get into the pros and cons of actually having this. But if you really want it, I guess you could have one dedicated Maven module for each site. Something like:
site-a
core
ui.apps
ui.content
ui.frontent
...
site-b
core
ui.apps
ui.content
ui.frontent
...
commons
core
ui.apps
ui.content
ui.frontent
...
dispatcher
If you can afford the effort of a refactoring, please observe I have added a commons Maven module, where you could add your common code (components, services etc) for any website.
As for Dispatcher, I guess you can have hosts (.vhost) and farms (.farm) for each site.
@Tethich - can you please provide sample parent reactor project structure. any sample pom file if you can share
please note , still we have only one git repo to use for both site-a and siteb
Views
Replies
Total Likes
I used to have only one repository as well and the structure I suggested worked fine with that.
So, the reactor pom.xml file would look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.domain</groupId>
<artifactId>myproject</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Reactor</name>
<description>Reactor</description>
<modules>
<module>all</module>
<module>commons</module>
<module>dispatcher</module>
<module>site-a</module>
<module>site-b</module>
</modules>
<properties>
<aem.host>localhost</aem.host>
<aem.port>4502</aem.port>
<aem.publish.host>localhost</aem.publish.host>
<aem.publish.port>4503</aem.publish.port>
<sling.user>admin</sling.user>
<sling.password>admin</sling.password>
<vault.user>admin</vault.user>
<vault.password>admin</vault.password>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<frontend-maven-plugin.version>1.12.0</frontend-maven-plugin.version>
<core.wcm.components.version>2.19.0</core.wcm.components.version>
<bnd.version>5.1.2</bnd.version>
<aem.sdk.api>2025.1.19149.20250116T154450Z-241100</aem.sdk.api>
<aemanalyser.version>1.4.10</aemanalyser.version>
</properties>
.....
<build>...</build>
<dependencyManagement>...</dependencyManagement>
<profiles>...</profiles>
</project>
The <build>, <dependencyManagement> and <profiles> sections you can copy from what you already have. If not, you can generate a project structure using the archetype as per the documentation: https://experienceleague.adobe.com/en/docs/experience-manager-learn/getting-started-wknd-tutorial-de....
And the main pom file in site-a module would look something like:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.mydomain</groupId>
<artifactId>myproject</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>site-a</artifactId>
<name>Site A</name>
<packaging>pom</packaging>
<description>Site A</description>
<modules>
<module>core</module>
<module>ui.apps</module>
<module>ui.content</module>
<module>ui.frontend</module>
</modules>
</project>
@Tethich thanks so much for sharing the details . so using same above structure . what is the best way to setup . meaning Site-A already existing with default archetype structure
now Site-B setup needs to be done where site-B will be using same Site-A components except the new template and page component different. for this case what will the best way . should we still go with sub module structure or manually going in ui.apps and create different folder structure for Site-B and new components will just extend Site-A resourcetype , similarly for \ui.content\src\main\content\jcr_root\conf also Site-B folder structure and create template configuration ?
and later we also have Site-C which will be brand new i.e all new components and new template structure for pages . in this what will be the best way to plan the project structure to avoid restructuring later
Views
Replies
Total Likes
If you have different teams managing each site code base and/or you want to manage separately the release strategy and/or you must run independent gitflows, then I think having unique maven modules would be fit. And everything that is common from site-a would be moved to a commons module and extended from there in case customizations are required. Of course, this is doable when you have let's say a low number of sites, maybe up to 5 (it is not an exact rule).
The other approach, by keeping only one module, but create folder inside to differentiate the codebase for each site, in my view would be same thing in terms of amount of files to manage, but only more complicated and prone to errors. I would still keep things separately and cleaner.
If you think that you will have to support lots and lots of sites, each with mostly same components and services but just slightly different, then you might think of making the code smarter. Implement the logic to support different behaviors for different sites (or group of sites), keeping the number of components/services/templates etc as lower as you can manage them.
There is always a tradeoff between how flexible is your end solution and how maintainable it is.
Consider also using techniques like components proxing and components versioning.
Thanks @Tethich really helpful information
Views
Replies
Total Likes
We followed a similar approach suggested by @Tethich , but implemented it as a Git submodule since different teams were working on different sites. This setup allows each team to use its own repository for collaboration. Ideally, the Dispatcher module can be included in only one project, typically the commons project.
In our project we have only one ui.apps, ui.content, core module and we segregated the code and content within those modules and for dispatcher configs we have seperate vhost, farm and rule files.
You can create different repo as siteA and siteB then you can create one parent reactor project which will contains SiteA and SiteB as git modules.
site A project will have different maven strucuture
site B project will have different maven strucuture
@ASHISHIBM - can you please provide sample parent reactor project structure. any sample pom file if you can share
please note , still we have only one git repo to use for both site-a and siteb
@sonuk85184451 I think you need to create 2 repos for individual site and then parent one contains both the submodules
Views
Like
Replies