Dear Maven developers, I’d like to propose an idea for Maven to help its users better with the JPMS.
= Goals As a developer, I’d like to have all the following benefits. It seems to me that no existing approach provide them all. I assume a single- module project with some main code and some white box test code. – white box tests in the same Maven project as the main code – usual maven-recommended layout for main code and tests (src/main/java; src/test/java; …) — JPMS advantages for both main code and tests, such as, compilation and runtime checks that I do not break boundaries of what the modules I use intend as public API — non-redundant declarations of my (main code and test) dependencies – possibility of using some dependencies solely for the test code – clear specification for the behavior of main and test compilation and run wrt modular dependencies – support of main IDEs I suggest that Maven should make JPMS a first-class citizen in the POM, allowing the JPMS concepts to sit right where the rest of the project is configured. The POM would thus describe to the Maven system, in high-level, conceptual terms, what my modular dependencies are, and so on, so that Maven (and all plugins that want to access this information) knows everything it needs to build my module. It is open to discussion which syntactic form this should take (I think this is not crucial to the conceptual discussion about the qualities of this proposal). For example, the <dependency> element could include additional informations, describing whether I want some dependencies to become static or transitive module requirements (or omit them from module requirements, if this makes sense). A new first-level element could be defined to describe the packages and resources I want to export or open, and any other information required for Maven to completely understand my module. This would extend to describing also the test part of my code, of course. Armed with this rich information, Maven could auto-generate the module- info.java file before compiling the code; auto-generate the alternative module-info.java file before compiling and running the tests; and do all sorts of things that any plugin inventor could see fit to simplify the lives of developers. Seeing that this information could be found in a standardized part of the POM, IDE developers could build support for this in turn. = Motivation for first-class citizenry of JPMS data I realize that some similar idea is already being implemented (https://github.com/moditect/moditect/), or could be implemented using mere plugins, if dropping the requirement to change the basic POM description: just put every supplementary information required for the JPMS aspects inside the plugin configuration (that’s the approach currently chosen by moditect). On the contrary, making these JPMS configuration data a first-class part of the POM is a crucial part of the proposal, for the following reasons. First, it is conceptually right. JPMS configuration data is crucial to a modular project, on par with dependency information, and deserve to be not just inside the configuration section of a given plugin. Relatedly, splitting the versions-of-packages I depend on and the modules I depend on in two very distinct parts of the POM is conceptually odd and inelegant. I have read, and agree with, all those blog posts warning about module ≠ artifact, that the module system does not intend to solve the version-selection problem, and all the like, but this does not change the fact that many things related to my module graph can be deduced from my jar dependencies: those are not two completely separated world. Last but not least, it would send a strong signal from Maven to the Java community: this is the way Maven (not just a plugin developer) decided to approach the problem, this is the Maven proposal for a de- facto standard that we’ve all been waiting for since years. IDEs and project developers are waiting for such de-facto standard to emerge in order to know how to solve the modular-test conundrum (“since no actual standard exists, the exact rules must be determined” -- https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601#c11) and build further tools and support around that. Considering Maven’s popularity, it is not unlikely that many developers would start actually putting their data in the relevant sections of the POM rather sooner than later, which would further build the incentive for IDE developers to support it… = Inspiration for this proposal This proposal is inspired by two remarks from Alex Buckley in an exchange with Robert Scholte. (This is of course *not* to claim that Alex Buckley endorses this proposal; I have no idea about that.) “Is there nothing that Maven can do to make the test-compile configuration easier to create? Maven has all the source code at its fingertips, including knowledge of module directories which seem to declare the same module more than once because JUnit recommends it, yet still Maven makes the user laboriously write out the command line flags for patching?” -- https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-February/014368.html “there are other ways, where the build tools (or their plugins) take responsibility for arranging the test-time module graph. This may require more work on the part of build tool/plugin maintainers than simply telling their users to write JDK command line options in the middle of a config file.” -- https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-February/014383.html = Related ideas The moditect plugin, under development, could be used for inspiration about the syntax to adopt. However, it should be moved from the configuration section of this plugin to make it a first-class entry in the POM, alongside the existing dependency section and new one(s). I think I have read some exchange about this kind of ideas on the jigsaw-dev ML some years ago, but I can’t find it any more. IIRC, at that time there was hope that the JEP itself would standardize everything needed to test the code as well, so that Maven would not have to do it, so this path had not been developed further in the discussion at the time. But we now know that this never happened and will not happen. I have searched further, for example, on this ML (https://www.mail-archive.com/search?q=jpms&l=dev%40maven.apache.org&o=newest ), for other discussions of proposals similar to this one, but oddly enough, have not found any. Would this idea not work for some reason that has escaped me? Is there some other way that I am ignorant of that gathers all the advantages that I have listed? What are your thoughts? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
