You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Olivier Cailloux <ol...@gmail.com> on 2021/11/02 18:39:19 UTC
JPMS data as first-class citizen of the POM
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Ralph Goers <ra...@dslextreme.com>.
My 2 cents. I’ve spent many, many hours trying to make Log4j 2 JPMS compatible.
It is still nowhere near done. While JPMS sounds simple the side effects it has permeate
everything. If you were to look at the Log4j 2 master branch right now it is a complete
mess. Adding Java 9 support was bad enough because the JDK removed classes and
replaced them with others making it very difficult to have a single source code base that
worked in all supported Java versions. But JPMS probably tripled the complexity because
it was no longer simple to build test jars and unit tests in the same Maven module.
Although I do plan to finish the work and clean it up, I seriously doubt the work will have
been worth the effort. To date the requests for full JPMS support have been non-existent.
I’ve had more requests to support GraalVM than JPMS.
Ralph
> On Nov 5, 2021, at 2:01 AM, Christian Stein <so...@gmail.com> wrote:
>
> On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux <ol...@gmail.com>
> wrote:
>
>> ...
>> 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;
>>
> ...
>
>
> That's like saying: Hey Maven, generate my packages (and classes, and
> interfaces, and...)! ;-)
>
> Or as Robert expressed it: https://stackoverflow.com/a/43213506/1431016
> Also read his article linked in the answer.
>
> Cheers,
> Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Robert Scholte <rf...@apache.org>.
Keep in mind that the pom.xml is language agnostic, it describes
configuration that makes sense for any programming language.
Hence, the pom should not be extended with Java specific features.
Maven supports extensions, with seems like a better fit.
Configuring an extension is not standardized yet, now the extension can
pick up System properties of read some file from its preferred location.
The closest you can get right now is probable the
moditect-maven-plugin[1]
thanks,
Robert
[1] https://github.com/moditect/moditect
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Olivier Cailloux <ol...@dauphine.fr>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Christian Stein <so...@gmail.com>.
On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux <ol...@gmail.com>
wrote:
> ...
> 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;
>
...
That's like saying: Hey Maven, generate my packages (and classes, and
interfaces, and...)! ;-)
Or as Robert expressed it: https://stackoverflow.com/a/43213506/1431016
Also read his article linked in the answer.
Cheers,
Christian
Re: JPMS data as first-class citizen of the POM
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 6 nov. 2021 à 12:36, Olivier Cailloux <ol...@dauphine.fr>
a écrit :
> Le vendredi 05 novembre 2021 à 09:27 +0100, Romain Manni-Bucau a
> écrit :
> > 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.
>
> I agree that JPMS is not perfect, but, unless you propose that Maven
> should rather embrace openly OSGi, the comparison between these two is
> irrelevant. I propose to help users switch to JPMS, and most of those
> are not already using OSGi, and will not. (If they are, fine; JPMS and
> are compatible.) JPMS does represent a significant step forward, for
> the vast majority of developers not already using OSGi, that lets the
> Java ecosystem know something more about the dependency graph, and
> other improvements (see e.g. the book of Nicolai
> Parlog, https://www.manning.com/books/the-java-module-system).
>
Point was jpms is not the future for users so no need to priviledge it more
than some jpms packaging and lifecycle. Rest is already solved and
sufficient so plugins are enough.
> I do not think there is any value in you and I debating here over which
> of OSGi or JPMS is “better in general”. This question is meaningless.
> This discussion happened many times already, and leads to no
> consensus. Multiple pieces of opinion about it can be found easily,
> some mentioning the superiority of OSGi in terms of how large it
> embraces
> (https://www.infoq.com/articles/java9-osgi-future-modularity/), some
> highlighting that OSGi has much broader goals and therefore also higher
> complexity than JPMS
> (https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f).
>
> Let’s please try to overcome this lack of consensus and find a way
> forward for Java.
>
> JPMS would be much more used if proper tooling was easily available.
> Hence, my proposal under discussion here. It is no proper reply to
> refuse this proposal under pretext that JPMS is not widely used. This
> is a chicken-and-egg problem.
>
> The requirements I listed seem to me like a pretty natural and minimal
> list of things that an average developer would want to have in order to
> switch to JPMS. (Also considering the usual “tradegy of the commons”
> problem that I benefit from _other_ modules being JPMS-ized but not
> much from JPMS-ing mine in a world where the other ones are not yet.)
> Before this requirement list is effectively supported by tools that
> developers are used to (or close variants thereof), it is no strong
> surprise that the average developer does not delve into the effort of
> describing their modules formally for the ecosystem to benefit. For
> example, although I am enthousiastic about the possibilities and future
> offered by JPMS, I didn’t switch my projects to JPMS either, because I
> was waiting for proper tooling to emerge.
>
> Maven has an important role to play here.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: JPMS data as first-class citizen of the POM
Posted by Olivier Cailloux <ol...@dauphine.fr>.
Le vendredi 05 novembre 2021 à 09:27 +0100, Romain Manni-Bucau a
écrit :
> 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.
I agree that JPMS is not perfect, but, unless you propose that Maven
should rather embrace openly OSGi, the comparison between these two is
irrelevant. I propose to help users switch to JPMS, and most of those
are not already using OSGi, and will not. (If they are, fine; JPMS and
are compatible.) JPMS does represent a significant step forward, for
the vast majority of developers not already using OSGi, that lets the
Java ecosystem know something more about the dependency graph, and
other improvements (see e.g. the book of Nicolai
Parlog, https://www.manning.com/books/the-java-module-system).
I do not think there is any value in you and I debating here over which
of OSGi or JPMS is “better in general”. This question is meaningless.
This discussion happened many times already, and leads to no
consensus. Multiple pieces of opinion about it can be found easily,
some mentioning the superiority of OSGi in terms of how large it
embraces
(https://www.infoq.com/articles/java9-osgi-future-modularity/), some
highlighting that OSGi has much broader goals and therefore also higher
complexity than JPMS
(https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f).
Let’s please try to overcome this lack of consensus and find a way
forward for Java.
JPMS would be much more used if proper tooling was easily available.
Hence, my proposal under discussion here. It is no proper reply to
refuse this proposal under pretext that JPMS is not widely used. This
is a chicken-and-egg problem.
The requirements I listed seem to me like a pretty natural and minimal
list of things that an average developer would want to have in order to
switch to JPMS. (Also considering the usual “tradegy of the commons”
problem that I benefit from _other_ modules being JPMS-ized but not
much from JPMS-ing mine in a world where the other ones are not yet.)
Before this requirement list is effectively supported by tools that
developers are used to (or close variants thereof), it is no strong
surprise that the average developer does not delve into the effort of
describing their modules formally for the ecosystem to benefit. For
example, although I am enthousiastic about the possibilities and future
offered by JPMS, I didn’t switch my projects to JPMS either, because I
was waiting for proper tooling to emerge.
Maven has an important role to play here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ta...@cservenak.net> 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 <
> olivier.cailloux@gmail.com>
> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: JPMS data as first-class citizen of the POM
Posted by Olivier Cailloux <ol...@dauphine.fr>.
Le vendredi 05 novembre 2021 à 09:12 +0100, Tamás Cservenák a écrit :
> 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:
Thank you for this pointer. The “enforcing dependency usage” part
(http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation)
is indeed interesting, but I view it as less valuable now that there is
a Java standard to do this sort of things. I’d rather go for JPMS
support.
(Also, Takari can’t enforce the same things as JPMS without relying on
export module declarations.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ol...@gmail.com>
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>