elharo commented on issue #453: URL: https://github.com/apache/maven-ear-plugin/issues/453#issuecomment-5103885211
Gemini likes this one: This element has been part of the official Java EE (and now Jakarta EE) schema for enterprise applications since version 6. **This is a highly valid and worthwhile feature request.** It represents a gap in the plugin's implementation of the official specification, and resolving it aligns perfectly with the core purpose of the plugin. Here is a technical evaluation of why this feature should be implemented: 1. **Specification Alignment:** The primary responsibility of the `maven-ear-plugin` (when configured to generate the deployment descriptor) is to output a strictly compliant `application.xml` file. The `<data-source>` element is a standard, defined part of the `application_6.xsd` (and later) schemas. By lacking support for this element, the plugin is failing to fully implement the specification it is designed to support. 2. **Elimination of Fragile Workarounds:** Currently, users who need to define a data source at the EAR level are forced to completely disable the plugin's descriptor generation. They must generate the XML once, copy it to `src/main/application/META-INF/application.xml`, manually add the `<data-source>` block, and maintain the file statically going forward. This defeats the purpose of having the plugin dynamically manage module entries and configurations during the build lifecycle. 3. **Infrastructure as Code:** Defining standard application resources like data sources within the build configuration (POM) ensures that deployment requirements are version-controlled alongside the build logic. **Potential Implementation Considerations:** The only minor drawback to this feature is verbosity. As outlined in the issue, the `<data-source>` element accepts over a dozen nested properties (e.g., `class-name`, `port-number`, `initial-pool-size`, `isolation-level`). Implementing this will require adding a complex configuration object to the plugin's Mojo parameters. Consequently, configuring this inside a `pom.xml` will result in a lengthy XML block. However, because this configuration would be strictly optional, it imposes no burden on users who do not need it. Unlike previous requests that sought to modify core build lifecycle mechanics or support proprietary formats, this request asks the plugin to correctly output standard Jakarta EE metadata. It should be implemented. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
