Hi All,
We are currently migrating our legacy AEM project to the new Maven archetype (version 54). In the old setup, we had around 35 separate backend bundles, each with its own pom.xml. In the new structure, we’ve merged all these bundles into a single core bundle (as per adobe recommendation)
Challenge:
Any pointers or guidance would be greatly appreciated.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @AravindB1,
1. Missing or incorrect package exports after consolidation
Even though everything is now in one bundle, the OSGi classloader still relies on properly exported packages.
If some packages were implicitly exported in the old multi-bundle setup (because each bundle had its own exports), merging into a single core bundle may result in:
services not visible to each other
SCR not finding implementation classes
@Reference showing Unsatisfied even though provider is active
Check your core/pom.xml:
<Export-Package>
com.myproj.api.*,
com.myproj.services.*,
!
</Export-Package>
If a package containing an OSGi service or its interface is not exported, the DS resolver cannot wire the reference.
2. Multiple service interfaces now in the same bundle, but DS resolver detects cycles
In a large consolidated bundle, circular service dependencies become more obvious:
Service A → Service B → Service A
Previously they lived in different bundles, so resolution timing differed.
Now they load together -> DS marks one as Unsatisfied.
Check /system/console/depfinder for cycles.
3. Auto-install bundle deploy overwrites only one bundle, but dependent bundles are stale
When using:
mvn clean install -PautoInstallBundle
only core gets installed.
If some services or interfaces were previously in other bundles and AEM still has old bundles cached:
DS resolves against the old bundle first
references become unsatisfied after refresh
Verify using:
/system/console/bundles?sl=1
You might see:
old bundles still installed
export conflicts
Solution -> uninstall old bundles completely.
4. Component activation order changes in a single bundle
35 bundles -> 1 bundle means DS activation timing shifts.
A reference like:
@Reference(cardinality = ReferenceCardinality.MANDATORY)
private MyService myService;
may temporarily be unavailable during activation, causing Unsatisfied -> Active -> Unsatisfied oscillation when hot-deployed.
AEMaaCS and newer AEM SDKs are more strict about DS timing.
5. Mixed annotations (Felix SCR + OSGi R6) after migration
If part of the legacy code still uses:
@SlingServlet
@Service
@Component
…and the new code uses:
@Component(service = MyService.class)
SCR vs DS annotation processors can conflict after consolidation.
Run:
mvn clean install -Panalysis
and check for:
missing DS metadata
old SCR tags
components not registered at all
Views
Replies
Total Likes
Hello @AravindB1 ,
It appears that there is a sequential arrangement regarding how the bundles are organized within the single pom.xml file.
Could you kindly check the inter-dependencies of the bundles and work on arranging them in the correct sequence?
You can accomplish this by examining the unresolved dependencies in the unsatisfied bundles or by reviewing the error logs.
Hope this is helpful!
Thanks
Views
Replies
Total Likes
HI @AravindB1 ,
The "maven-bundle-plugin" in the core bundle's pom.xml needs to be updated to correctly export and import packages for the consolidated code.
Review the Export-Package and Import-Package instructions within the plugin configuration. Ensure that all necessary packages from the merged code are properly exported for other bundles to consume and that any required external packages are imported.
For example:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Bundle-Name>${project.name}</Bundle-Name>
<Export-Package>
com.yourproject.core.components.*,
com.yourproject.core.services.*,
<!-- Add other packages to export from the merged code -->
</Export-Package>
<Import-Package>
!org.apache.felix.scr.annotations, <!-- Avoid importing SCR annotations directly -->
*
</Import-Package>
</instructions>
</configuration>
</plugin>
Hope it helps!
-Tarun
Views
Replies
Total Likes
Views
Like
Replies
Views
Likes
Replies