Think JPMS is not different from OSGi in terms of requirement (it is more broken than OSGi and less used only) so not sure why it would pollute the pom, plus depending how you setup your project you don't use the same thing so it would hurt maven convention phylosophy IMHO. So it is good to stick to plugins for JPMS IMHO.
@Tamás: if this takari really brings some boost due to the reduced dependencies and no regression, any hope it hits maven default distro with "jar" packaging? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 5 nov. 2021 à 09:13, Tamás Cservenák <[email protected]> a écrit : > 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] > > > > >
