You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add integration tests and fix default reconciliation merging
Addresses reviewer feedback on PR apache#389:
1. Add integration tests for default reconciliation behavior:
- Test with no executionControl configuration (uses defaults)
- Test with executionControl for different plugin (verifies merging)
2. Fix reconciliation config resolution to merge defaults with explicit config:
- Explicit configs take precedence when present
- Default reconciliation configs apply when no explicit config exists
- Ensures compiler defaults work even when other plugins are configured
3. Add null safety checks to prevent NPE in unit tests:
- Check for null mojoExecution before accessing
- Check for null plugin before matching
Integration tests verify that:
- Changing maven.compiler.release invalidates cache as expected
- Changing maven.compiler.source/target invalidates cache
- Default reconciliation still applies when executionControl configures other plugins
Add test for explicit config overriding defaults
Completes integration test coverage requested by reviewer:
1. ✅ No configuration set - DefaultReconciliationTest
2. ✅ No plugin configuration set - DefaultReconciliationTest
3. ✅ Plugin reconciliation overrides defaults - DefaultReconciliationOverrideTest (NEW)
4. ✅ Plugin reconciliation merges with defaults - DefaultReconciliationWithOtherPluginTest
The new test verifies that when executionControl explicitly configures
maven-compiler-plugin, the explicit config completely OVERRIDES the
defaults rather than merging:
- Explicit config tracks only 'release' property
- Changing 'source' DOES hit cache (proves 'source' not tracked)
- Changing 'release' does NOT hit cache (proves 'release' is tracked)
- If defaults merged, 'source' would also be tracked (but it's not)
This confirms the implementation correctly handles both override and
merge scenarios as requested.
Implement plugin parameter export/categorization system
Addresses reviewer suggestion to create extensible configuration system:
**Architecture:**
- Plugin parameter definitions stored as XML files in classpath
- Each plugin has its own XML file (e.g., maven-compiler-plugin.xml)
- Parameters categorized as "functional" or "behavioral"
- Validation system checks reconciliation configs against definitions
**Components:**
1. **XML Schema** (plugin-parameters.xsd):
- Defines structure for parameter definitions
- Enforces functional/behavioral categorization
- Validates at build time
2. **Parameter Definitions**:
- maven-compiler-plugin.xml: 30+ parameters for compile/testCompile goals
- maven-install-plugin.xml: 12+ parameters for install/install-file goals
- Comprehensive categorization based on whether parameter affects output
3. **Java Infrastructure**:
- PluginParameterDefinition: Model classes for definitions
- PluginParameterLoader: Loads XML from classpath
- Validation logic in CacheConfigImpl
4. **Validation Features**:
- ERROR on unknown parameters (may indicate plugin changes)
- WARN on behavioral parameters in reconciliation config
- WARN when no definition exists for plugin
- Validates all default reconciliation configs on initialization
**Benefits:**
- Detects plugin parameter changes/renames automatically
- Prevents incorrect behavioral parameters in reconciliation
- Self-documenting: XML files serve as parameter catalog
- Extensible: Add new plugins by creating XML files
- Type-safe: Enforces functional/behavioral distinction
**Testing:**
- Unit tests verify parameter loading and categorization
- Validates that default reconciliation params are functional
- All 20 existing tests pass + 3 new validation tests
This creates a "closed and matching set of parameters" as requested,
ensuring the default configuration fails/warns on unknown parameters
and preventing incorrect behavior from plugin modifications.
Add user documentation for parameter validation system
Updates documentation to explain the new parameter categorization and
validation features:
**how-to.md additions:**
- New "Parameter Validation and Categorization" section
- Explains functional vs behavioral parameter categories
- Documents validation features (ERROR/WARN on unknown/misclassified params)
- Provides example XML for adding new plugin definitions
- Notes that defaults are overridden by explicit config per-plugin
- Lists current coverage (maven-compiler-plugin, maven-install-plugin)
**concepts.md additions:**
- Reference to parameter validation system
- Link to detailed how-to documentation
- Context within correctness vs performance tradeoff discussion
This documentation will appear on the Maven website, making the feature
discoverable and providing clear guidance for:
- Understanding why certain parameters are tracked
- Adding validation for new plugins
- Troubleshooting unknown parameter warnings
- Extending the system as plugins evolve
Fix integration test version placeholder
Use ${projectVersion} instead of @project.version@ to match the resource filtering pattern used by other integration tests.
Fix integration tests to check for reconciliation behavior
- Fix XML config structure: executionControl is sibling of configuration, not child
- Update test assertions to check for 'Plugin parameter mismatch found' message
- Reconciliation happens at runtime after cache lookup, not during hash calculation
- Tests now correctly verify that parameter changes trigger rebuild via reconciliation
Add version-specific parameter definition support
- Update XSD schema to support minVersion element
- Implement version-aware parameter loading with best-match selection
- Add version comparison logic handling SNAPSHOT qualifiers
- Update validation to use plugin version at runtime
- Add comprehensive tests for version-specific loading
- Update documentation with version support examples
Version matching selects the definition with highest minVersion <= plugin version.
Multiple version-specific definitions can coexist in a single XML file.
This allows accurate validation as plugin APIs evolve across versions.
Load default reconciliation configs from XML instead of hardcoding
- Create default-reconciliation.xsd schema for defaults
- Add defaults.xml with maven-compiler-plugin and maven-install-plugin configs
- Implement DefaultReconciliationLoader to load configs from XML
- Replace hardcoded defaults in CacheConfigImpl with XML loading
- Update documentation to reflect XML-based configuration
This makes defaults extensible - projects can provide their own
default-reconciliation/defaults.xml on the classpath.
0 commit comments