Business Value
Running or debugging Citrus XML tests via the plugin corrupts the user's saved run configurations and executes tests with wrong settings, forcing users to manually fix their configurations after every use.
Problem / Context
Both XmlTestExecuteAbstractAction and XmlTestSelectConfigurationAbstractAction create a copy of the selected run configuration via selectedConfiguration.createFactory().create() to avoid modifying the original.
However, the instanceof pattern variable javaTestConfigurationBase still references the original configuration from selectedConfiguration.getConfiguration().
All subsequent mutations (setName(), setVMParameters()) are applied to the original, not the copy.
This causes two symptoms:
- The copy that is actually executed via ProgramRunnerUtil.executeConfiguration() never receives the -Dtests.to.run= parameter or the correct name, resulting in a default configuration with wrong settings.
- The original saved configuration is permanently mutated, with -Dtests.to.run= accumulating on every invocation.
Solution Approach
After creating the copy, read VM parameters from the original, then apply name, VM parameters, and before-run tasks to copyRunConfSettings.getConfiguration() instead.
Acceptance Criteria
- The executed copy contains the correct -Dtests.to.run=TestFileName VM parameter
- The original run configuration's VM parameters remain unchanged after execution
- Existing VM parameters from the original are preserved in the copy
- Before-run tasks are copied to the new configuration
- Fix applies to both direct execution and select-configuration actions
Business Value
Running or debugging Citrus XML tests via the plugin corrupts the user's saved run configurations and executes tests with wrong settings, forcing users to manually fix their configurations after every use.
Problem / Context
Both XmlTestExecuteAbstractAction and XmlTestSelectConfigurationAbstractAction create a copy of the selected run configuration via selectedConfiguration.createFactory().create() to avoid modifying the original.
However, the instanceof pattern variable javaTestConfigurationBase still references the original configuration from selectedConfiguration.getConfiguration().
All subsequent mutations (setName(), setVMParameters()) are applied to the original, not the copy.
This causes two symptoms:
Solution Approach
After creating the copy, read VM parameters from the original, then apply name, VM parameters, and before-run tasks to copyRunConfSettings.getConfiguration() instead.
Acceptance Criteria