{{{#!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 perform the same computation on an externally supplied classpath.

Tooling that inspects a third-party application requires 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 that FileManager provides at runtime). It has the reactor’s compile classpath available, but cannot pass 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 includes a shim class, `McpResourcePaths`, declared in the ` com.top_logic.basic.core.workspace ` package but compiled into the plugin JAR, so it can access PathInfo’s package-private builder API on the flat plugin classpath. It replicates the classpath-entry dispatch from ` Workspace.addClassPathEntry`. This is a split-package workaround that will remain in place only until the engine provides a supported entry point.

Proposed change

Extract the classpath-driven core of ` getAppPaths(String, String[]) ` into a new public overload that explicitly accepts the classpath, and have the existing method delegate to it using 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 behavioral change for existing callers (the JVM classpath remains unchanged). Once released, the McpResourcePaths shim in tl-mcp-server is removed and its caller is switched to this overload.