Howdy, Not in vanilla maven, but just FYI: I think all these benefits (along with boundary checks but Maven not JPMS sense) are provided by takari lifecycle: http://takari.io/book/40-lifecycle.html
Thanks T On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux <[email protected]> wrote: > 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] > >
