Move InputLocation/InputLocationTracker/InputSource to velocity templates

[gnodet]

Summary

This PR moves the InputLocation, InputLocationTracker, and InputSource classes from maven-api-model to be generated using the existing velocity templates in src/mdo/java/.

Changes Made

Updated Velocity Templates

• InputLocation.java: Added Maven-specific features controlled by isMavenModel parameter:

  • importedFrom field and constructor support
  • Copy constructor for InputLocation
  • Maven-specific toString() format using String.format()
  • getImportedFrom() method implementation

• InputLocationTracker.java: Added Maven-specific getImportedFrom() method when isMavenModel=true

• InputSource.java: Added Maven-specific features:

  • modelId field and related constructors
  • inputs collection for merged sources
  • importedFrom field
  • Maven-specific equals(), hashCode(), and toString() methods
  • merge() static method for combining sources

Removed Manual Classes

• Deleted manually written InputLocation.java, InputLocationTracker.java, and InputSource.java from api/maven-api-model/src/main/java/org/apache/maven/api/model/

Benefits

1. Consistency: InputLocation classes are now generated consistently across all Maven modules using the same templates
2. Maintainability: Changes to InputLocation functionality can now be made in one place (the templates) rather than maintaining separate manual implementations
3. Feature Parity: All Maven-specific features are preserved through the isMavenModel boolean parameter
4. Code Reuse: The same templates can generate both simple and Maven-enhanced versions of these classes

Testing

• ✅ Successfully generated classes using modello plugin
• ✅ Verified generated classes contain all Maven-specific features
• ✅ Full Maven build passes with mvn clean install -DskipTests

The implementation uses the existing isMavenModel boolean parameter pattern that was already established in the codebase, ensuring consistency with the existing approach for handling differences between Maven and other model types.

[elharo]

I strongly prefer code to be Java instead of some other random format (here mdo). Given that the Java code already exists, I don;t see why we would want to throw it away in favor of generated code.

[gnodet]

I strongly prefer code to be Java instead of some other random format (here mdo). Given that the Java code already exists, I don;t see why we would want to throw it away in favor of generated code.

The current state is we have 5 times those 3 classes in different packages :

• 4 generated
• one hard coded

I'd rather avoid duplication, hence this proposal to reduce to a single set of generated classes.

I really don't think we should avoid generation and favour duplication instead. It will become a nightmare to maintain. And there's more than just those 15 classes.

[gnodet]

Maven Code Generation Analysis Report

Executive Summary

This analysis examines the code generation efficiency in the Apache Maven project, comparing the lines of code (LOC) in input files (MDO model definitions and Velocity templates) versus the generated Java output files.

Key Findings

Input Files

• Total Input Files: 23 files
  • MDO Files: 13 files (8,026 lines, 7,514 effective)
  • VM Templates: 10 files (4,371 lines, 2,374 effective)
• Total Input LOC: 12,397 lines (9,888 effective)

Generated Output

• Generated Java Files: 208 files
• Generated LOC: 73,331 lines

Code Generation Ratios

• Overall Generation Ratio: 5.91x (73,331 ÷ 12,397)
• Effective Generation Ratio: 7.41x (73,331 ÷ 9,888)
• File Multiplication Factor: 9.04x (208 ÷ 23)

Detailed Breakdown

Input Files Analysis

MDO Files (Model Definition Objects)

The largest MDO files by line count:

1. api/maven-api-model/src/main/mdo/maven.mdo - 3,582 lines (core Maven model)
2. its/core-it-suite/src/test/resources/mng-7629/child-1/src/main/mdo/settings.mdo - 1,083 lines
3. api/maven-api-settings/src/main/mdo/settings.mdo - 1,051 lines
4. api/maven-api-plugin/src/main/mdo/plugin.mdo - 617 lines
5. api/maven-api-metadata/src/main/mdo/metadata.mdo - 410 lines

VM Templates (Velocity Templates)

The VM templates by complexity:

1. reader.vm - 1,107 lines (681 effective) - Generates XML readers
2. reader-stax.vm - 835 lines (452 effective) - Generates StAX readers
3. model.vm - 525 lines (197 effective) - Generates model classes
4. writer-stax.vm - 521 lines (275 effective) - Generates StAX writers
5. model-v3.vm - 342 lines (174 effective) - Generates v3 compatibility models

Generated Files Analysis

By File Type

Type	Files	Lines	Purpose
Model Classes	175	46,635	Core data model objects
Reader Classes	10	11,701	XML/configuration readers
Writer Classes	10	4,612	XML/configuration writers
Transformer Classes	4	3,661	Model transformation utilities
Merger Classes	4	5,580	Configuration merging logic
Version Classes	5	1,142	Version handling utilities

By Module (Top Contributors)

Module	Generated Files	Purpose
compat/maven-model	46	Legacy model compatibility
api/maven-api-model	45	Core API model classes
compat/maven-settings	20	Settings compatibility layer
impl/maven-support	19	Implementation support classes
api/maven-api-settings	18	Settings API classes

Code Generation Efficiency

Productivity Metrics

• Lines per Input File: 3,188 generated lines per input file on average
• Most Productive Template: reader.vm generates approximately 11,701 lines from 681 effective lines (17.2x ratio)
• Most Productive MDO: maven.mdo (3,582 lines) generates approximately 45 files

Template Efficiency

Each VM template serves a specific purpose:

• Model templates (model.vm, model-v3.vm) generate the core data structures
• I/O templates (reader*.vm, writer*.vm) generate serialization/deserialization code
• Utility templates (merger.vm, transformer.vm) generate helper functionality

Conclusions

1. High Code Generation Efficiency: The 5.91x generation ratio demonstrates that Maven's code generation system is highly effective at producing large amounts of consistent, boilerplate code from concise definitions.

2. Template Reusability: 10 VM templates generate 208 Java files across multiple modules, showing excellent template reusability.

3. Model-Driven Architecture: The system successfully implements a model-driven approach where business logic is captured in MDO files and implementation details are handled by templates.

4. Maintenance Benefits: With nearly 6x code generation ratio, maintaining the 23 input files is significantly more efficient than manually maintaining 208 generated files.

5. Consistency: Generated code follows consistent patterns and conventions, reducing bugs and improving maintainability.

Recommendations

1. Template Optimization: Consider optimizing templates with lower generation ratios
2. Documentation: The high generation ratio justifies investment in comprehensive template documentation
3. Testing: Automated testing of generated code is crucial given the multiplication factor
4. Version Control: Generated files should be excluded from version control to avoid conflicts

---

Analysis performed on Apache Maven codebase - maven-4.0.x branch