Loose EAR Manifest Class-Path Issue Fix by sajeerzeji · Pull Request #1073 · OpenLiberty/ci.gradle

sajeerzeji · 2026-03-24T10:28:05Z

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,

Scans both compileClasspath and runtimeClasspath for project dependencies
Automatically adds each dependency's class and resource directories to the module in loose XML
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

…ifest, Adds that dependency's class and resource directories to the module archive element in the loose XML

venmanyarun

as discussed, add tests

cherylking · 2026-03-24T14:42:43Z

src/main/groovy/io/openliberty/tools/gradle/utils/LooseEarApplication.groovy

+                    if (jarName && jarName.endsWith(".jar")) {
+                        String depName = jarName.replace(".jar", "")
+
+                        def depProj = proj.rootProject.findProject(":${depName}")


Are we guaranteed that the dependency project name is the jarName without .jar? I wouldn't think so. We will be missing dependencies if they don't match right?

I did a research on this and found below cases, we can do fallback matching for these cases

Custom archiveBaseName - Projects using archiveBaseName = 'custom-name' produce JARs that don't match the project name

Versioned JARs - Projects with archiveVersion = '1.0' produce JARs like ProjectName-1.0.jar instead of ProjectName.jar

Classified JARs - Projects using archiveClassifier = 'client' produce JARs like ProjectName-client.jar for different variants

Combined customizations - Projects combining base name, version, and classifier produce complex names like custom-2.0-prod.jar

Additionally

Completely custom archiveFileName - Projects using archiveFileName = 'xyz-database-layer.jar' have no relationship between project name and JAR name

Dynamic JAR names - Projects computing JAR names at runtime using expressions like "${env}-${project.name}.jar" may not be resolvable at configuration time

Nested projects with custom naming - Multi-level projects (:parent:child) using custom base names like archiveBaseName = 'parent-child-combined' require path-based matching

cherylking · 2026-03-24T14:43:49Z

src/main/groovy/io/openliberty/tools/gradle/utils/LooseEarApplication.groovy

-                    //The location of the resource directory should be the same as proj.getProjectDir()/build/resources.
-                    //If the manifest file exists, it is copied to proj.getProjectDir()/build/resources/tmp/META-INF. If it does not exist, one is created there.
-                    addManifestFileWithParent(moduleArchive, f, proj.sourceSets.main.getOutput().getResourcesDir().getParentFile().getCanonicalPath())
+                    // Prefer the jar task's generated manifest (build/tmp/jar/MANIFEST.MF) which has


Do we need to do something similar for Liberty Maven plugin?

@sajeerzeji Please check by creating similar project in Liberty Maven plugin and try deploying the EAR to see issue exists in LMP

Sure, will do this and will update here

cherylking · 2026-03-24T14:47:12Z

src/main/groovy/io/openliberty/tools/gradle/utils/LooseEarApplication.groovy

        }
+        // If no .MF file was found in the jar source set (e.g. no static MANIFEST.MF in resources),
+        // still add the jar task's generated manifest if it exists.
+        if (!manifestAdded) {


Are we sure we should always do this? We don't even know if any files were added above for this module. Is this ok to do for war and rar?

…' into GH766-Multi_module_issue_with_loose_app

sajeerzeji · 2026-03-27T14:05:47Z

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,

Scans both compileClasspath and runtimeClasspath for project dependencies
Automatically adds each dependency's class and resource directories to the module in loose XML
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.

src/main/groovy/io/openliberty/tools/gradle/utils/LooseEarApplication.groovy

src/test/groovy/io/openliberty/tools/gradle/TestMultiModuleLooseEarEjbDependency.groovy

venmanyarun · 2026-04-06T10:18:11Z

src/test/resources/multi-module-loose-ear-ejb-dependency-test/settings.gradle

@@ -0,0 +1,8 @@
+rootProject.name = 'ejb-dependency'
+include ':lib-jar'


here I can see we have direct dependency with both lib-jar and ejb-jar
we should have tests that have

Multi-level transitive dependencies (A depends on B depends on C)

Mixed dependency types (project + external JARs)

venmanyarun · 2026-04-06T10:19:10Z

@sajeerzeji
can you add screen recording ?

Instead of using static resource manifest, use jar task generated man…

1d48694

…ifest, Adds that dependency's class and resource directories to the module archive element in the loose XML

sajeerzeji requested review from cherylking and venmanyarun March 24, 2026 10:28

venmanyarun requested changes Mar 24, 2026

View reviewed changes

cherylking requested changes Mar 24, 2026

View reviewed changes

Sajeer added 4 commits March 27, 2026 18:50

EJB Dependency Fixes

0d44cfd

Reverts the changes

f274dfd

Merge branch 'multi-module-loose-app-projects-not-copying-deps-to-lib…

9718506

…' into GH766-Multi_module_issue_with_loose_app

Logs corrected

7ef518c

venmanyarun requested changes Apr 6, 2026

View reviewed changes

Absolute dirNodes count check added to the test

70b422f

sajeerzeji requested a review from cherylking April 10, 2026 13:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Loose EAR Manifest Class-Path Issue Fix#1073

Loose EAR Manifest Class-Path Issue Fix#1073
sajeerzeji wants to merge 6 commits intoOpenLiberty:mainfrom
sajeerzeji:GH766-Multi_module_issue_with_loose_app

sajeerzeji commented Mar 24, 2026 •

edited

Loading

Uh oh!

venmanyarun left a comment

Uh oh!

cherylking Mar 24, 2026

Uh oh!

sajeerzeji Mar 25, 2026

Uh oh!

cherylking Mar 24, 2026

Uh oh!

venmanyarun Mar 25, 2026

Uh oh!

sajeerzeji Mar 25, 2026

Uh oh!

cherylking Mar 24, 2026

Uh oh!

sajeerzeji commented Mar 27, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

venmanyarun Apr 6, 2026

Uh oh!

venmanyarun commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -0,0 +1,8 @@
		rootProject.name = 'ejb-dependency'
		include ':lib-jar'

Conversation

sajeerzeji commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue

Uh oh!

venmanyarun left a comment

Choose a reason for hiding this comment

Uh oh!

cherylking Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

sajeerzeji Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

cherylking Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

venmanyarun Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

sajeerzeji Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

cherylking Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

sajeerzeji commented Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

venmanyarun Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

venmanyarun commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sajeerzeji commented Mar 24, 2026 •

edited

Loading

sajeerzeji commented Mar 27, 2026 •

edited

Loading