On Sat, 24 Nov 2018 15:02:08 +0100, Martin Desruisseaux
<martin.desruisse...@geomatys.com> wrote:
Le 24/11/2018 à 13:53, Robert Scholte a écrit :
With the Java Platform Modular System you'll clearly see different
requirements between library and application developers.
Indeed (e.g. jlink is for application developers), but the requirements
I'm talking about are for library developers.
Keep in mind that 1 pom-file can represent only 1 module. If you want
to distribute multiple modules, you will still need a multimodule
Maven project.
Yes and no. 1 pom-file can represent only one artifact. But the rest of
the discussion assumed that 1 artifact = 1 module, or that 1 Maven
module = 1 Jigsaw module. This relationship does not necessarily hold.
From recent discussion on OpenJDK public mailing list [1]:
I'm sure the topic of executable modular JARs files be back on the
table some day but it needs to be looked at in conjunction with the
issues around having multiple modules in the same artifact. They
would be likely be work needed in several Maven plugins and other
parts of the eco system too. In the mean-time, it's not too hard to
package multiple modules into the same JAR file and have a main
class that creates a configuration and module layer from the modules
in the JAR files.
Another possibility is to generate the pom.xml files for each Jigsaw
module, by intersecting the parent pom.xml with module-info.
There is no clean way to do this yet.
Single invocation only makes sense for an application that won't share
modules.
No - a single javac invocation on a multi-modules projects still
generate .class files in separated directories for each Jigsaw module,
which result in one JAR file per module. I good demonstration of that is
NetBeans modular projects (based on Ant), which does exactly that. I
would like to see the same capability in Maven.
So yes: single invocation is an option for the jdk tools but doesn't
fit in the Maven architecture and is probably in general not that
needed.
It does not fit with Maven standard directory layout. But with a change
of layout and corresponding changes in Maven plugins, I do not see major
obstacle (but of course I do not have your deep knowledge of Maven
internal). However I would not said that this is generally not needed.
We have at least MJAVADOC-449. Together with other issues, for me the
choice is between an evolution of Maven (possibly with custom plugins)
or migrating to another build system. Furthermore other Jigsaw evolution
may come (e.g. above-cited multiple modules in same artifact). If Maven
does not become more Jigsaw-friendly, the amount of difficulties may
increase in the future.
Today I started looking at MJAVADOC-449 again and it seems that just
nobody took serious time to solve this.
I've been able to create the proper commandline by moving some classpath
entries to the modulepath.
Now it is a matter of implementing this.
There are no plans to make these changes in Maven.
As response Remi Forax wrote Pro[1], which is build upon these new jdk
tools features combined with the concepts of Maven.
Yes I'm aware of that, and my proposal is in part bringing some of Remi
Forax's idea into Maven.
I'll wait for the PRs :)
No, module-path is not the issue, but module-source-path is, which
expects an extra folder reflection the module-name.
Indeed - this is the correction email I posted after my previous email.
I don't understand this issue. As a java developer wanting to add
module descriptor, you only have to create
src/main/java/module-info.java. You can build your project as you are
used to.
Adding module-info.java is sufficient for generating the JAR file, but
this is not the end of development process. We also needs to generate
javadoc. We sometime want to run annotation processing tools. Those
extra tasks are where difficulties arise. There is also a circular
dependency problem that would be solved with my proposal, but this one
is admittedly quite specific to a project.
Martin
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056839.html
[2] https://issues.apache.org/jira/browse/MJAVADOC-449
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
