Le vendredi 05 novembre 2021 à 10:01 +0100, Christian Stein a écrit : > Or as Robert expressed it: > https://stackoverflow.com/a/43213506/1431016 > Also read his article linked in the answer.
Thank you, I wish I had seen this article sooner (https://www.sitepoint.com/maven-cannot-generate-module-declaration/), I would have taken these arguments into consideration while writing my original post. Let me do it now. = The arguments of the article Considering the content of the article, I think its title could be “Why Maven Generating Your Module Declaration requires a new POM” rather than “Why Maven Cannot Generate Your Module Declaration”. Most of the content of the article indeed argues that such a generation does require more information to be put into the POM. I obviously agree, as visible in my proposal. Now, the article also indicates that it is not desirable to change Maven’s POM specification, but does not argue forcefully about this specific point. I only see two short arguments in the article about this claim. == First argument against POM change First, changing the POM would require some change to existing plugins, as it would change the XSD. I agree that this is no light decision to take: nobody wants Maven to change its POM XSD every two months and have numerous plugins frequently break because of that. But the JPMS is an important change to the ecosystem, one that will not happen again soon; and it makes sense that it requires some new information into the POM to support it. Moreover, some not-too-painful migration paths can be thought of (see Appendix). == Second argument against POM change The second argument from the article is that changing the POM to support auto module-info generation brings no important benefit, as the POM would require as much work to configure generation properly as maintaining the module-info file itself. This is an important exageration, as the Maven dependencies can often be transformed automatically into module requirements (as observed in another part of the article). That some other piece of information can’t be reduced is compatible with an overall reduction, in fact, even, complete suppression, of redundancy. (The relevant criterion is not the number of keystrokes spared but whether I have to maintain redundant information or not.) But the most important point is not there: this auto-generation does not only permit reduction of redundancy. My proposal aims at supporting a specific list of requirements (listed in my original post), which such a change of POM XSD enables. As I wrote in a previous reply in this thread, the list of requirements in my original post seems like a basic requirement list for any average developer to desire when considering embracing JPMS. And I am not aware of any approach that support it. = Conclusion It would be good that Maven participate in the advent of an ecosystem where artifacts use a standard way of describing their modular dependencies, thereby bringing multiple benefits of the JPMS with nice tooling support. This requires a slight change of the POM. Isn’t this worth it? Wouldn’t it be a huge missed opportunity if this never happens on a large scale because developers are hindered by lack of support? = Appendix: migration to a new POM model Here is a rough proposal for migration to an extended POM XSD which would optionally admit supplementary information required for generation of JPMS module-info. Users are encouraged to write a pm.xml file instead of pom.xml file. The pm.xml file uses the new XSD. It has essentially the same content as the old one, but can admit supplementary information such as, in <dependency> entries, something that describes whether the exported module should be exported as “transitive requirements”, or the exported packages (alternatively, for the exports specifically, users could be encouraged to Java-annotate their packages, to reduce verbosity). Maven reads the pm.xml file if found instead of pom.xml, and starts by generating a pom.xml file on the fly if it detects that backwards compatibility need to be ensured (that is, if the user has requested it or some plugins not compatible with the new XSD are referenced in the PM). The generated pom.xml conforms to the “old” XSD, thus, omitting any information about modules. This ensures that plugins not updated for the new XSD still work. (The generated pom.xml file also contains some property to indicate that it is auto-generated.) Plugin authors are encouraged to upgrade their plugin to accept the new XSD (I suspect that many will have no code to change, unless they want to add functionality related to the module system). They write in their plugin POM some property that advertises to the Maven system that their plugin is compatible with the new XSD. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
