Loose EAR Manifest Class-Path Issue Fix

[sajeerzeji]

Fixes #766

Issue

The application failed to start in loose EAR mode with,

StateChangeException: Error while loading class com.ibm.websphere.svt.gs.gsdb.session.MfgCategorySessionBean
ResourceLoadingException: Error while loading JPA entity classes (MfgCategory, Category, etc.)

In packaged EAR mode, JAR files are physically present in the EAR, and Liberty's classloader uses the manifest Class-Path entries to locate dependency JARs within the EAR.

In loose EAR mode (looseApplication = true), there are no physical JAR files. Instead, the plugin generates an XML descriptor (GarageSaleLibertyEAR.ear.xml) that maps source directories. Liberty's classloader needs to know which class directories belong to each module.

The Problem

• EJB modules depend on other modules (e.g., JPA modules) via compileOnly or implementation dependencies
• The plugin only added the EJB module's own classes to the loose XML
• Dependency class directories were not included, causing ClassNotFoundException at runtime

Previous Approach (Reverted)
The previous fix attempted to use manifest Class-Path entries to determine dependencies, requiring users to manually declare Class-Path in their build.gradle files. This approach was reverted after cross-checking with Maven plugin implementation.

Current Approach
Added addDependencyClassDirectories() method that,

1. Scans both compileClasspath and runtimeClasspath for project dependencies
2. Automatically adds each dependency's class and resource directories to the module in loose XML
3. Works without requiring manifest Class-Path configuration

How it works

• Plugin automatically detects project dependencies from Gradle configurations
• For each EJB/JAR module, it finds all project dependencies
• Adds dependency class directories as <dir> elements in the loose XML
• Liberty's classloader can now find all required classes at runtime

Usage Requirements
No special configuration needed. The plugin automatically handles dependencies declared in build.gradle.

Backward Compatibility

• Packaged EAR mode (looseApplication = false) continues to work unchanged
• Existing projects work without modification

Testing
Added a new test TestMultiModuleLooseEarEjbDependency that verifies

• Loose application XML is generated correctly
• EJB modules include dependency class directories
• Module's own classes are still included

Before

After

[venmanyarun]

as discussed, add tests

[sajeerzeji]

Hi @cherylking
After reviewing the changes in this PR against the Maven plugin implementation, I identified a gap in the approach. I've reverted the previous changes and implemented a new fix as below,

Previous approach was to use manifest Class Path entries to determine dependencies, requiring users to manually declare Class-Path in their build.gradle files. This approach was reverted after cross-checking with Maven plugin implementation.

Added addDependencyClassDirectories() method that,

1. Scans both compileClasspath and runtimeClasspath for project dependencies
2. Automatically adds each dependency's class and resource directories to the module in loose XML
3. Works without requiring manifest Class-Path configuration

Now the plugin automatically detects project dependencies from Gradle configurations, for each EJB/JAR module, it finds all project dependencies, adds dependency class directories as <dir> elements in the loose XML.

[venmanyarun]

@sajeerzeji
can you add screen recording ?

[sajeerzeji]

@sajeerzeji can you add screen recording ?

Screen.Recording.2026-04-13.at.4.29.14.PM.mov

[cherylking]

Looks like most of the builds are failing. So I am not going to look at the changes further until they are passing.

[sajeerzeji]

Looks like most of the builds are failing. So I am not going to look at the changes further until they are passing.

Test are passed once re-ran, the issues where network connection timeout in InstallLiberty_runtimeUrl tests.