Expand my Community achievements bar.

SOLVED

Setting multiple websites in AEM as cloud service

Avatar

Level 5

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

 

sonuk85184451_0-1739267796783.png

 

@arunpatidar @konstantyn_diachenko @Jörg_Hoh 

 

 

1 Accepted Solution

Avatar

Correct answer by
Level 9

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.

 

View solution in original post

18 Replies

Avatar

Community Advisor

Hi @sonuk85184451 

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.



Arun Patidar

Avatar

Level 5

@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

               

                    sonuk85184451_0-1739283048514.png

then later for another site say site-b , manually new structure was created ?

 

                 site-b

                        ui.apps

                        sonuk85184451_0-1739283048514.png

 

                                          

      

                  

Avatar

Community Advisor

HI @sonuk85184451 

I meant

ui.apps/src/main/content/jcr_root/apps/site-a/components

ui.apps/src/main/content/jcr_root/apps/site-b/components



Arun Patidar

Avatar

Level 5

@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 

Avatar

Community Advisor

Hi @sonuk85184451 

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.



Arun Patidar

Avatar

Level 5

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 ?

Avatar

Community Advisor

yes,you can directly use it, since the code for site-a and site-b are in the same bundle



Arun Patidar

Avatar

Level 9

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.

Avatar

Level 5

@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

Avatar

Level 9

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>

Avatar

Level 5

@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 

Avatar

Correct answer by
Level 9

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.

 

Avatar

Level 5

Thanks @Tethich  really helpful information 

Avatar

Level 7

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.

Avatar

Level 1

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.

Avatar

Level 2

@sonuk85184451 

 

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

Avatar

Level 5

@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

Avatar

Level 2

@sonuk85184451 I think you need to create 2 repos for individual site and then parent one contains both the submodules