Create a new lightweight goal/task that evaluates all the configuration and creates the liberty-plugin-config.xml potentially without installing Liberty itself and without creating the server itself

[venmanyarun]

Problem statement: When the end user edits Liberty configuration files in a new project that has not been built yet, certain information about the project is not known in LCLS and Liberty Tools. The key information not known has to due with what Liberty is being used (Open Liberty or WebSphere Liberty, what version?), which configuration files and properties are being used (the LMP/LGP does a lot of processing and combining of information included in the build file for configuration such as server.env, bootstrap.properties, jvm.options, and the server config files themselves).

To know the true effective configuration in use by the project, the create server goal/task must be run at a minimum and that automatically does the Liberty install before copying over all the config to the newly created server. Once that is done, the liberty-plugin-config.xml file exists in the target/build directory and contains vital information about the configuration that can be used by LCLS/Liberty Tools when doing diagnostics.

Solution: Create a new lightweight goal/task that evaluates all the configuration and creates the liberty-plugin-config.xml potentially without installing Liberty itself and without creating the server itself , but mocking the server structure so that variable processing can be done

Similar goal is suggested as part of #1094

[venmanyarun]

key changes are as follows

• mocking the directory structure of server to copyConfigFiles() so that we can use mocked directory for variable processing until user triggers actual server creation/ dev mode
• variable processing in LCLS will be triggered just after the liberty-plugin-config.xml is generated in LibertyDiagnosticsParticipant
• Change in FileWatchService to re-trigger variable processing if liberty-plugin-config.xml is updated ( this would make sure variables are refreshed if user creates a server/dev mode is started)
• Change in FileWatchService to re-trigger prepare-config and variable processing if any file in liberty config directory is updated ( this would work similar to automatic file copying in dev mode)

Metadata Used by LCLS from liberty-plugin-config.xml

lemminx-liberty (Language Server)

• installDirectory - Load Liberty runtime metadata for variable resolution
• serverDirectory - Locate server.xml and related config files
• userDirectory - Access shared configuration files
• serverOutputDirectory - Resolve output directory variables
• configFile - Custom server.xml location, used for non-standard paths

liberty-ls (Legacy Language Server)

• serverEnv - Custom server.env file path
• bootstrapPropertiesFile - Custom bootstrap.properties file path
• configDirectory - Configuration directory location

---

Part 1: Liberty Plugin Flow (Maven/Gradle)

Command Execution

# Maven
mvn liberty:prepare-config

# Gradle
gradle libertyPrepareConfig

Step 1: Plugin Invocation

User or IDE executes prepare-config command. Plugin framework initializes the goal/task and reads configuration from pom.xml (Maven) or build.gradle (Gradle).

Step 2: Goal/Task Initialization

Reads build configuration and initializes plugin parameters:

• includeServerInfo = true (default) - Controls whether to include server-specific information
• serverName from configuration (default: "defaultServer")
• installDirectory, configDirectory, userDirectory, outputDirectory from configuration
• Validates skip parameter, exits early if skip is true

Step 3: Create Mock Liberty Server Structure

Creates directory structure in build output folder:

• Maven: Creates target/tmp/wlp/usr/servers/{serverName}/ directory structure
• Gradle: Creates build/tmp/wlp/usr/servers/{serverName}/ directory structure
• Mimics actual Liberty server layout without installing Liberty
• All directories created with proper permissions
• Returns the mock server directory path for subsequent operations

Step 4: Copy Configuration Files to Mock Server

Uses parent class copyConfigFiles() method which handles:

• Copies all files from configured configDirectory if specified
• Uses explicit file overrides (serverXmlFile, jvmOptionsFile, bootstrapPropertiesFile, serverEnvFile)
• Applies inline bootstrap properties and JVM options if configured in build file
• Executes mergeServerEnv logic if configured
• Resolves build property references (Maven: ${property}, Gradle: ${property}) in all config files
• Processes <include> elements in server.xml
• Temporarily sets serverDirectory to mock location before copying, then restores original value

Step 5: Read Project Information

Extract project metadata from build configuration:

• Reads project coordinates: groupId, artifactId, version, packaging type
• Collects all compile-scope and runtime-scope dependencies with their coordinates
• Identifies active build profiles (Maven) or configurations (Gradle)

Step 6: Generate Configuration XML

Builds mock directory paths and saves original directory values for restoration. Overrides directories to point to mock structure:

• Maven: Sets installDirectory to target/tmp/wlp
• Gradle: Sets installDirectory to build/tmp/wlp
• Sets userDirectory to {buildDir}/tmp/wlp/usr
• Sets serverDirectory to {buildDir}/tmp/wlp/usr/servers/{serverName}
• Sets outputDirectory to {buildDir}/tmp/wlp/usr/servers

Creates XML document with root element <liberty-plugin-config>:

Always-Included Elements:

• <installDirectory>, <userDirectory>, <serverDirectory>, <serverOutputDirectory> - All point to mock structure
• <serverName>, <projectType>, <activeBuildProfiles>, <projectCompileDependency> - Project metadata

Server-Specific Information (if includeServerInfo=true):

• <configDirectory>, <configFile>, <bootstrapPropertiesFile>, <serverEnv>, <jvmOptionsFile>
• <appsDirectory>, <looseApplication>, <applicationFilename>

Calls parent implementation with mock directories, then restores original directory values.

Step 7: Write Configuration File

Writes XML content to build output directory:

• Maven: target/liberty-plugin-config.xml
• Gradle: build/liberty-plugin-config.xml

Closes file handles and verifies file was written successfully.

Step 8: Completion

Logs success messages and returns success status to build tool.