{{{#!java public static PathInfo getAppPaths(Iterable<Path> classpathEntries, String deployDir, String[] deployAspects) }}}

Motivation

com.top_logic.basic.core.workspace.Workspace currently computes the web application resource path stack (stacked src/main/webapp directories and -web-fragment.war overlays, in override order) only for the running JVM's own classpath:

{{{#!java public static PathInfo getAppPaths(String deployDir, String[] deployAspects) }}}

The two entry points (getAppPaths() and the applicationModules(...) helper) both scan Workspace.class.getClassLoader() and System.getProperty("java.class.path"). There is no public way to run the same computation over an externally supplied classpath.

Tooling that inspects a foreign application needs exactly that. The tl-mcp-server Maven plugin builds an index of a target reactor and wants to expose that reactor's virtual web-resource filesystem (the same view FileManager provides at runtime). It has the reactor's compile classpath in hand, but cannot feed it to Workspace, because the driver loop and PathInfo's builder methods (addClasspathEntry, addClassesDir, addProject, addJar, complete) are package-private.

Current workaround (to be removed)

tl-mcp-server ships a shim class McpResourcePaths, declared in package com.top_logic.basic.core.workspace but compiled into the plugin jar, so it can reach PathInfo's package-private builder API on the flat plugin classpath. It duplicates the classpath-entry dispatch from Workspace.addClassPathEntry. This is a split-package hack kept only until the engine offers a supported entry point.

Proposed change

Extract the classpath-driven core of getAppPaths(String, String[]) into a new public overload that accepts the classpath explicitly, and have the existing method delegate to it with the JVM's own classpath:

{{{#!java public static PathInfo getAppPaths(String deployDir, String[] deployAspects) throws IOException {

return getAppPaths(currentJvmClasspath(), deployDir, deployAspects);

}

public static PathInfo getAppPaths(Iterable<Path> classpathEntries, String deployDir, String[] deployAspects)

throws IOException {
PathInfo result = new PathInfo(deployDir, deployAspects);
for (Path entry : classpathEntries) {
addClassPathEntry(result, entry);
}
result = result.complete();
return result;

} }}}

No behavioural change for existing callers (the JVM-classpath path is unchanged). Once released, the McpResourcePaths shim in tl-mcp-server is deleted and its caller switched to this overload.