Re: Status of JPMS support in compiler plugin
Le 2025-04-01 à 08 h 37, Gary Gregory a écrit : What Piotr describes is sadly the kind of insane setup one must have to work with JPMS and keeps me saying JPMS is something to work around, not work with. I think that what Piotr described is a Maven issue, not a JPMS issue. The problem is that Maven 3 sometime setups JPMS in awkward ways. For example, when testing a project with a module-info.java in the test sources, Maven 3 declares `src/test/java` as the main code and `src/main/java` as the patch applied over the tests. It is not surprising that we observe weird behavior, and not really fair to blame JPMS for that. What I really want is a --jpms-off toolchain switch... I think that this switch already exists is some way: put everything on the classpath. However, we have few control in Maven 3 about where to place dependencies. But again, this is a Maven 3 problem, not a JPMS problem. It should be resolved in Maven 4: a developer can declare all dependencies with `classpath-jar` if this is really wanted. Note, however, that if a library is modular by design, it may not work at all on the classpath. For example, the library may declare its services in module-info only, without copy in `META-INF/services`. Or it may depend on `java.lang.ModuleLayer`. No --jpms-off switch will "fix" that. Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Status of JPMS support in compiler plugin
Le 2025-04-01 à 11 h 07, Gary Gregory a écrit : I suppose it feels like Java is still being developed in an ivory tower away from the real world. The constant reinventing the wheel (logging and http client APIs are obvious examples). I suppose OSGi vs. JPMS could fall into this category. The balance is sometime difficult to find. I do not know which arguments were debated inside Oracle. But I'm involved in debates inside another (non-Java) standardization organization, where the same thing is said: why an international standard should reinvent the wheel when an existing library already does the work? Some reasons that are debated are: * Consistency. An organization such as ISO (for example) tries to keep a consistent pattern between standards. They do not fully succeed, but at least they try. Existing projects, by contrast, tend to be independent from each other and therefore heterogeneous. So a standard organization can receive on one side complains that it reinvent the wheel, and on the other side complains that its standards lack consistency. * Important use cases. A project may cover the needs of the individuals who developed it and said that it covers 95% of the needs of the market. That may be true, but if the remaining 5% drives nuclear power plans or airports, this is something that a standard organization needs to take in account. I'm not saying that what Oracle did is right or wrong. I'm just saying that, if their experience is similar to what I have see in standardization organizations, they may be faced to more difficult decisions than what we may imagine from outside. Martin
Re: Status of JPMS support in compiler plugin
Typo: Le 2025-04-01 à 10 h 17, Martin Desruisseaux a écrit : It would require the maven-jar-plugin to generate one JAR per Maven module. Was intended to be "one JAR per Java module". Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Status of JPMS support in compiler plugin
Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit : The https://github.com/nipafx/module-tooling/ repo seems to be private. Is there any public place to follow the discussion? Not as far as I know. The initiator of this discussion wanted to keep it private, I'm not sure why. This topic has been raised on this mailing list before: https://lists.apache.org/thread/vwgw2q7t0p5k4o0j20q3y8l15ymlpdby Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Status of JPMS support in compiler plugin
Hi Martin, Thank you for your thoughtful comments. I suppose it feels like Java is still being developed in an ivory tower away from the real world. The constant reinventing the wheel (logging and http client APIs are obvious examples). I suppose OSGi vs. JPMS could fall into this category. All of this to say that I wish existing tooling like Maven had been taken into account or have been brought in for collaboration such that JPMS and Maven could have been in lockstep. We probably didn't have the resources on the Apache side for that I imagine. Gary On Tue, Apr 1, 2025, 09:55 Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2025-04-01 à 08 h 37, Gary Gregory a écrit : > > > What Piotr describes is sadly the kind of insane setup one must have > > to work with JPMS and keeps me saying JPMS is something to work > > around, not work with. > I think that what Piotr described is a Maven issue, not a JPMS issue. > The problem is that Maven 3 sometime setups JPMS in awkward ways. For > example, when testing a project with a module-info.java in the test > sources, Maven 3 declares `src/test/java` as the main code and > `src/main/java` as the patch applied over the tests. It is not > surprising that we observe weird behavior, and not really fair to blame > JPMS for that. > > > > What I really want is a --jpms-off toolchain switch... > I think that this switch already exists is some way: put everything on > the classpath. However, we have few control in Maven 3 about where to > place dependencies. But again, this is a Maven 3 problem, not a JPMS > problem. It should be resolved in Maven 4: a developer can declare all > dependencies with `classpath-jar` if this is really wanted. > > Note, however, that if a library is modular by design, it may not work > at all on the classpath. For example, the library may declare its > services in module-info only, without copy in `META-INF/services`. Or it > may depend on `java.lang.ModuleLayer`. No --jpms-off switch will "fix" > that. > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Status of JPMS support in compiler plugin
On Tue, Apr 1, 2025, 10:19 Piotr P. Karwasz wrote: > Hi Martin, > > On 1.04.2025 11:03, Martin Desruisseaux wrote: > > Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit : > >> The https://github.com/nipafx/module-tooling/ repo seems to be > >> private. Is there any public place to follow the discussion? > > > > Not as far as I know. The initiator of this discussion wanted to keep > > it private, I'm not sure why. This topic has been raised on this > > mailing list before: > > > > https://lists.apache.org/thread/vwgw2q7t0p5k4o0j20q3y8l15ymlpdby > > > Thanks, I have seen this thread before, but I didn't know if the > initiative started or not. > > I am happy to know it started and it is the same initiative that was > mentioned in the thread. If you can make the discussion public at some > point it would be even better. > +1 it would be great to be able to track this effort publicly. Gary > Piotr > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Status of JPMS support in compiler plugin
Hi Martin, On 1.04.2025 10:17, Martin Desruisseaux wrote: I am also afraid that such a structure will really break IDEs: Eclipse already breaks if there is a separate module descriptor for tests, putting multiple JPMS modules in the same Maven Project will probably also break IDEA. Yes, it would require changes in IDEs. But the https://github.com/nipafx/module-tooling/ project has been started for discussing the problem of module support in tooling. The discussion includes developers from Oracle, IDEA, Eclipse, Gradle and Maven. The topic of modular project layout has been one discussion among others and I have not see resistance so far. The Eclipse developer already took some action in anticipation for that (improved support of the --module-source-path in Eclipse compiler) as a result of this discussion. The https://github.com/nipafx/module-tooling/ repo seems to be private. Is there any public place to follow the discussion? When it comes to JPMS and the current Maven Compiler Plugin, what I mostly miss it the possibility to have two source and output folders for tests: unit/whitebox tests need to break encapsulation and either run on the classpath or with `--patch-module`, while integration/blackbox tests should run from a separate JPMS module. I can volunteer for implementing that. We currently have "test" which is interpreted as whitebox testing. We need to have the community to agree on a new scope for blackbox testing and add it to Maven Core. It would need to be added to `ProjectScope`, and I guess probably `DependencyScope` as well. After such scope has been added to the core, I can implement blackbox testing in the compiler plugin. That would be nice. The "test" scope is currently heavily overloaded: it contains both compile and runtime dependencies for both whitebox and blackbox testing. At Apache Logging I am not sure if we would be able to use the new scopes, since we use custom JUnit extensions in blackbox testing and we release them. We will probably always need at least two Maven Modules. Piotr - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Status of JPMS support in compiler plugin
Hello Piotr Le 2025-04-01 à 08 h 20, Piotr P. Karwasz a écrit : I fail to understand, however, the purpose of the "modular project" layout. All modules are compiled in one single calls to `javac`. It is not one call of `javac` per module. The benefit is that forward references to dependent modules (the opposite of references to dependencies) are resolved by the compiler. Such forward references appear in at least 2 places: Javadoc @see, @link and @linkplain tags, and qualified exports and opens statements in module-info. The modular layout allows the compiler to verify those references and emit warnings or errors if they are wrong. There is no way (as far as I know) to get this safety without "modular project" layout. This is an opt-in feature: if a developer doesn't want it, nothing force it to use it. But those who want this safety as no way (as far as I know) to get it without such layout. As far as I know, there is currently no support for multiple JPMS modules in the same JAR. True, which is why the wiki page said that the "one to one" relationship between Java modules and Maven artifacts is preserved. It would require the maven-jar-plugin to generate one JAR per Maven module. I already have a working prototype on Gradle. The POM is generated for each artifact by taking the dependencies declared in the user POM, and omitting the dependencies that are not declared in the module-info of each Java module. The artifact ID needs to be specified by the user in plugin configuration. That said, while there is no mutli-modules JAR files at this time, discussions that I have see from times to times on OpenJDK mailing lists give me the impression that such format may appear in the future. I am also afraid that such a structure will really break IDEs: Eclipse already breaks if there is a separate module descriptor for tests, putting multiple JPMS modules in the same Maven Project will probably also break IDEA. Yes, it would require changes in IDEs. But the https://github.com/nipafx/module-tooling/ project has been started for discussing the problem of module support in tooling. The discussion includes developers from Oracle, IDEA, Eclipse, Gradle and Maven. The topic of modular project layout has been one discussion among others and I have not see resistance so far. The Eclipse developer already took some action in anticipation for that (improved support of the --module-source-path in Eclipse compiler) as a result of this discussion. When it comes to JPMS and the current Maven Compiler Plugin, what I mostly miss it the possibility to have two source and output folders for tests: unit/whitebox tests need to break encapsulation and either run on the classpath or with `--patch-module`, while integration/blackbox tests should run from a separate JPMS module. I can volunteer for implementing that. We currently have "test" which is interpreted as whitebox testing. We need to have the community to agree on a new scope for blackbox testing and add it to Maven Core. It would need to be added to `ProjectScope`, and I guess probably `DependencyScope` as well. After such scope has been added to the core, I can implement blackbox testing in the compiler plugin. Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Status of JPMS support in compiler plugin
Hi Martin, On 1.04.2025 11:03, Martin Desruisseaux wrote: Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit : The https://github.com/nipafx/module-tooling/ repo seems to be private. Is there any public place to follow the discussion? Not as far as I know. The initiator of this discussion wanted to keep it private, I'm not sure why. This topic has been raised on this mailing list before: https://lists.apache.org/thread/vwgw2q7t0p5k4o0j20q3y8l15ymlpdby Thanks, I have seen this thread before, but I didn't know if the initiative started or not. I am happy to know it started and it is the same initiative that was mentioned in the thread. If you can make the discussion public at some point it would be even better. Piotr - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
