[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849583#comment-17849583
]
Gili commented on SUREFIRE-1811:
[~Pavel_K] What you are trying to do violates the rules of Java Modules. By
definition, an application cannot import the same Java Module from two
different sources.
What's the point of sticking your tests in a module with the same name? Just
pick a different name.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-369) Adding module-info.java breaks JMH annotation processor
[
https://issues.apache.org/jira/browse/MCOMPILER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848993#comment-17848993
]
Gili commented on MCOMPILER-369:
Now that nabble is dead, the above discussion can be found at
https://mail.openjdk.org/pipermail/jigsaw-dev/2016-November/010201.html
> Adding module-info.java breaks JMH annotation processor
> ---
>
> Key: MCOMPILER-369
> URL: https://issues.apache.org/jira/browse/MCOMPILER-369
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.0
>Reporter: Gili
>Priority: Major
> Attachments: annotation-processor-jigsaw.zip
>
>
> # Open testcase
> # Run {{clean install}}. Notice that the benchmarks run.
> # Open {{pom.xml}} and comment-out the {{
> section.}}
> # Run {{clean install}}. Notice that the annotation processor does not run
> and the benchmarks break.
> # Delete/rename {{module-info.java}}.
> # Run {{clean install}}. Notice that the benchmarks work again.
> The documentation for {{}} states that by default
> annotation processors are detected from the classpath. It seems that adding
> {{module-info.java}} breaks that somehow, which is weird/unexpected because
> JMH exists as a dependency outside the newly-declared module.
> I did two things to prove that the annotation processor is not being invoked
> in step 4:
> # Notice that {{target/test-classes/META-INF}} is not created.
> # Place a breakpoint in {{org.openjdk.jmh.generators.BenchmarkProcessor}}
> and notice that it is never even constructed.
> I tried digging into the maven-compiler-plugin and plexus-compiler
> source-code but couldn't figure out where the problem is. The only workaround
> I found is to specify {{annotationProcessorPaths}} manually but it took me
> half a day to track down this problem.
> Any idea what is going on? Is this a bug in the plugin(s)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-310) [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
[
https://issues.apache.org/jira/browse/MJAR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847404#comment-17847404
]
Gili commented on MJAR-310:
---
If the bug is in plexus-utils, we should probably fix it there too because a
lot of other plugins depend on it. I would hate to have to file a separate bug
report for each one of them.
> [REGRESSION] Plugin fails to handle toolchain paths that contain spaces
> ---
>
> Key: MJAR-310
> URL: https://issues.apache.org/jira/browse/MJAR-310
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0, 3.4.1
> Environment: Maven 3.9.6
> Windows 10
>Reporter: Gili
>Priority: Major
> Fix For: next-release
>
>
> When upgrading from version 3.3.0 to 3.4.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8124) Allow regex usage in any profile activation key/value
Gili created MNG-8124: - Summary: Allow regex usage in any profile activation key/value Key: MNG-8124 URL: https://issues.apache.org/jira/browse/MNG-8124 Project: Maven Issue Type: Improvement Components: Profiles Affects Versions: 3.9.6 Reporter: Gili Following up on https://issues.apache.org/jira/browse/MNG-5726 I'd like to request allowing the use of regex for any key/value pair. For example, one should be able to use regex in property names or values, OS names or values, etc. Justification: Many users have been asking for the ability to logically-OR multiple conditions. Allowing the use of regex will go a long way in resolving those use-cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846736#comment-17846736
]
Gili commented on MNG-8121:
---
[~cstamas] [https://gist.github.com/cstamas/69e6365bbb70521923020d68369bf8e5]
is excellent, thank you. I'll try migrating away from nexus-maven-plugin. If
you don't hear back from me, it means it worked :)
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0, 4.0.0-beta-3
>
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846618#comment-17846618
]
Gili edited comment on MNG-8121 at 5/15/24 12:54 PM:
-
[~sjaranowski] I think you nailed it, but I also think that [~cstamas] has
missed an important use-case that only nexus-staging-plugin seems to handle:
deploying artifacts from different machines into the same staging environment.
In the context of cmake-maven-plugin and other projects that deploy native
artifacts, we build the project on different machines. Then each machine
uploads native files specific to that platform into the same staging
environment. Then, we tag all the files as a single release.
Correct me if I'm wrong, but I don't think this is possible using
release-maven-plugin.
In the context of nexus-staging-plugin, we are trying to deploy using the same
"stagingRepositoryId" and "stagingProfileId" values from multiple machines.
Is it possible to do this using maven-deploy-plugin somehow? Here is our GitHub
Action for releasing to Maven Central:
https://github.com/cmake-maven-project/cmake-maven-project/blob/v3.27.7-b1/.github/workflows/deploy_to_maven_central.yml
was (Author: cowwoc):
[~sjaranowski] I think you nailed it, but I also think that [~cstamas] has
missed an important use-case that only nexus-staging-plugin seems to handle:
deploying artifacts from different machines into the same staging environment.
In the context of cmake-maven-plugin and other projects that deploy native
artifacts, we build the project on different machines. Then each machine
uploads native files specific to that platform into the same staging
environment. Then, we tag all the files as a single release.
Correct me if I'm wrong, but I don't think this is possible using
release-maven-plugin.
In the context of nexus-staging-plugin, we are trying to deploy using the same
"stagingRepositoryId" and "stagingProfileId" values from multiple machines.
Is it possible to do this using maven-deploy-plugin somehow?
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
>
[jira] [Comment Edited] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846618#comment-17846618
]
Gili edited comment on MNG-8121 at 5/15/24 12:53 PM:
-
[~sjaranowski] I think you nailed it, but I also think that [~cstamas] has
missed an important use-case that only nexus-staging-plugin seems to handle:
deploying artifacts from different machines into the same staging environment.
In the context of cmake-maven-plugin and other projects that deploy native
artifacts, we build the project on different machines. Then each machine
uploads native files specific to that platform into the same staging
environment. Then, we tag all the files as a single release.
Correct me if I'm wrong, but I don't think this is possible using
release-maven-plugin.
In the context of nexus-staging-plugin, we are trying to deploy using the same
"stagingRepositoryId" and "stagingProfileId" values from multiple machines.
Is it possible to do this using maven-deploy-plugin somehow?
was (Author: cowwoc):
[~sjaranowski] I think you nailed it, but I also think that [~cstamas] has
missed an important use-case that only nexus-staging-plugin seems to handle:
deploying artifacts from different machines into the same staging environment.
In the context of cmake-maven-plugin and other projects that deploy native
artifacts, we build the project on different machines. Then each machine
uploads native files specific to that platform into the same staging
environment. Then, we tag all the files as a single release.
Correct me if I'm wrong, but I don't think this is possible using
release-maven-plugin.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
[jira] [Commented] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846618#comment-17846618
]
Gili commented on MNG-8121:
---
[~sjaranowski] I think you nailed it, but I also think that [~cstamas] has
missed an important use-case that only nexus-staging-plugin seems to handle:
deploying artifacts from different machines into the same staging environment.
In the context of cmake-maven-plugin and other projects that deploy native
artifacts, we build the project on different machines. Then each machine
uploads native files specific to that platform into the same staging
environment. Then, we tag all the files as a single release.
Correct me if I'm wrong, but I don't think this is possible using
release-maven-plugin.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846480#comment-17846480
]
Gili edited comment on MNG-8121 at 5/15/24 3:21 AM:
This issue seems to be related to
https://issues.apache.org/jira/browse/MPLUGIN-384 and
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/metadata/AddPluginArtifactMetadataMojo.java#L90]
I suspect that it is ultimately a duplicate of
https://issues.apache.org/jira/browse/MNG-7375 which is blocked on
[https://github.com/apache/maven/pull/645]
Meaning, maven-plugin-plugin 3.13.0 is incompatible with Maven 3.x. It can only
be used with Maven 4.x. And the resulting error message (NullPointerException)
makes it extremely difficult to figure out what is wrong.
I urge you to fix the situation in maven-plugin-plugin. Version 3.12.0 and
older work just fine, making this feel like a regression. If you are unable to
support Maven 3.x in this and subsequent versions, at the very least the plugin
should return a cleaner error message.
was (Author: cowwoc):
This issue seems to be related to
https://issues.apache.org/jira/browse/MPLUGIN-384 and
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/metadata/AddPluginArtifactMetadataMojo.java#L90]
I suspect that it is ultimately a duplicate of
https://issues.apache.org/jira/browse/MNG-7375 which is blocked on
[https://github.com/apache/maven/pull/645]
Meaning, maven-plugin-plugin 3.13.0 is incompatible with Maven 3.x. It can only
be used with Maven 4.x. And the resulting error message (NullPointerException)
makes it extremely difficult to figure out what is wrong.
Please improve the situation in maven-plugin-plugin. At the very least we
should get a cleaner error message. Better yet would be to handle this scenario
correctly in the plugin. It is a regression in the sense that older versions
worked fine.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
>
[jira] [Commented] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846480#comment-17846480
]
Gili commented on MNG-8121:
---
This issue seems to be related to
https://issues.apache.org/jira/browse/MPLUGIN-384 and
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/metadata/AddPluginArtifactMetadataMojo.java#L90]
I suspect that it is ultimately a duplicate of
https://issues.apache.org/jira/browse/MNG-7375 which is blocked on
[https://github.com/apache/maven/pull/645]
Meaning, maven-plugin-plugin 3.13.0 is incompatible with Maven 3.x. It can only
be used with Maven 4.x. And the resulting error message (NullPointerException)
makes it extremely difficult to figure out what is wrong.
Please improve the situation in maven-plugin-plugin. At the very least we
should get a cleaner error message. Better yet would be to handle this scenario
correctly in the plugin. It is a regression in the sense that older versions
worked fine.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MNG-8121:
--
Environment:
Maven 3.9.6
maven-plugin-plugin 3.13.0
org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
was:
Maven 3.9.6
maven-plugin-plugin 3.13.0
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846472#comment-17846472
]
Gili edited comment on MNG-8121 at 5/15/24 2:44 AM:
I just confirmed the problem by running the build through a debugger. When
merge() is invoked on "cmake-binaries-plugin" the for loop returns a plugin
where preExisting.getPrefix() returns null.
Looking at
[https://github.com/sonatype/nexus-maven-plugins/blob/43a9940b134c3f87ebe4daa82552e844d9c578b8/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/deploy/strategy/AbstractDeployStrategy.java#L107]
the "cmake-binaries-plugin" returns two instances of ArtifactMetadata:
# ArtifactRepositoryMetadata
# ProjectArtifactMetadata
but because none of them is an instanceof GroupRepositoryMetadata, pluginPrefix
remains equal to null.
This is probably the crux of the matter.
# Is the nexus plugin wrong to use GroupRepositoryMetadata to look up the
plugin's prefix? Or,
# Is does maven-plugin-plugin contain a regression and GroupRepositoryMetadata
should be returned?
I await your feedback.
was (Author: cowwoc):
I just confirmed the problem by running the build through a debugger. When
merge() is invoked on "cmake-binaries-plugin" the for loop returns a plugin
where preExisting.getPrefix() returns null.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846472#comment-17846472
]
Gili commented on MNG-8121:
---
I just confirmed the problem by running the build through a debugger. When
merge() is invoked on "cmake-binaries-plugin" the for loop returns a plugin
where preExisting.getPrefix() returns null.
> NullPointerException at
> org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
>
>
> Key: MNG-8121
> URL: https://issues.apache.org/jira/browse/MNG-8121
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.6
> Environment: Maven 3.9.6
> maven-plugin-plugin 3.13.0
>Reporter: Gili
>Priority: Major
>
> TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)}} throws {{NullPointerException}} if previous releases of
> a plugin did not have a goalPrefix set.
>
> At least, this is my interpretation of what is going on.
>
> Background
> -
>
> I have an open-source project at
> [https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
> with the following coordinates:
>
> com.googlecode.cmake-maven-project
> cmake
>
> If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced
> to set "" because of
> https://issues.apache.org/jira/browse/MPLUGIN-450 and
> [https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
>
> In my particular case, I set "cmake-binaries" inside
> cmake-binaries-plugin/pom.xml.
> Now, when I try deploying a release to Maven Central I get the following
> exception stack trace:
>
>
> {noformat}
> java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:293)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:99)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:59)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:56)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:399)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:294)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:202)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:393)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:131)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> (AbstractDeployStrategy.java:213)
> at
> org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
> (StagingDeployStrategy.java:125)
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:213)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126){noformat}
>
> I assume that this is caused by {{preExisting.getPrefix()}} returning null,
> but I have no idea why this is happening. Perhaps this is caused by previous
> versions not have a goalPrefix set? Shouldn't the implementation handle this
> possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
[
https://issues.apache.org/jira/browse/MNG-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MNG-8121:
--
Description:
TL;DR {{org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)}} throws {{NullPointerException}} if previous releases of a
plugin did not have a goalPrefix set.
At least, this is my interpretation of what is going on.
Background
-
I have an open-source project at
[https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
with the following coordinates:
com.googlecode.cmake-maven-project
cmake
If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced to
set "" because of https://issues.apache.org/jira/browse/MPLUGIN-450
and
[https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
In my particular case, I set "cmake-binaries" inside
cmake-binaries-plugin/pom.xml.
Now, when I try deploying a release to Maven Central I get the following
exception stack trace:
{noformat}
java.lang.NullPointerException
at org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
(AbstractRepositoryMetadata.java:99)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
(AbstractRepositoryMetadata.java:59)
at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
(MetadataBridge.java:56)
at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:399)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:294)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:202)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:393)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
(DefaultArtifactDeployer.java:131)
at
org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
(AbstractDeployStrategy.java:213)
at
org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
(StagingDeployStrategy.java:125)
at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
(DeployMojo.java:213)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126){noformat}
I assume that this is caused by {{preExisting.getPrefix()}} returning null, but
I have no idea why this is happening. Perhaps this is caused by previous
versions not have a goalPrefix set? Shouldn't the implementation handle this
possibility?
was:
TL;DR org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293) throws NullPointerException if previous releases of a
plugin did not have a goalPrefix set.
At least, this is my interpretation of what is going on.
Background
-
I have an open-source project at
[https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
with the following coordinates:
com.googlecode.cmake-maven-project
cmake
If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced to
set "" because of https://issues.apache.org/jira/browse/MPLUGIN-450
and
[https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
In my particular case, I set "cmake-binaries" inside
cmake-binaries-plugin/pom.xml.
Now, when I try deploying a release to Maven Central I get the following
exception stack trace:
{noformat}
java.lang.NullPointerException
at org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
(AbstractRepositoryMetadata.java:99)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
(AbstractRepositoryMetadata.java:59)
at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
(MetadataBridge.java:56)
at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:399)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:294)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:202)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:393)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
(DefaultArtifactDeployer.java:131)
at
org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
(AbstractDeployStrategy.java:213)
[jira] [Created] (MNG-8121) NullPointerException at org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
Gili created MNG-8121:
-
Summary: NullPointerException at
org.apache.maven.artifact.repository.metadata.Metadata.merge (Metadata.java:293)
Key: MNG-8121
URL: https://issues.apache.org/jira/browse/MNG-8121
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.9.6
Environment: Maven 3.9.6
maven-plugin-plugin 3.13.0
Reporter: Gili
TL;DR org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293) throws NullPointerException if previous releases of a
plugin did not have a goalPrefix set.
At least, this is my interpretation of what is going on.
Background
-
I have an open-source project at
[https://github.com/cmake-maven-project/cmake-maven-project/tree/v3.27.1-b1]
with the following coordinates:
com.googlecode.cmake-maven-project
cmake
If I upgrade "maven-plugin-plugin" from version 3.10.1 to 3.13.0 I am forced to
set "" because of https://issues.apache.org/jira/browse/MPLUGIN-450
and
[https://github.com/apache/maven-plugin-tools/commit/ed4774bcd8b8d2d1f7ff1196cf7644054cb3ae14#diff-624cbd32cd7fc0f3f9154fbec92b8a1aebb04614360b4a0b5fc28a407e99d743L96]
In my particular case, I set "cmake-binaries" inside
cmake-binaries-plugin/pom.xml.
Now, when I try deploying a release to Maven Central I get the following
exception stack trace:
{noformat}
java.lang.NullPointerException
at org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
(AbstractRepositoryMetadata.java:99)
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
(AbstractRepositoryMetadata.java:59)
at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
(MetadataBridge.java:56)
at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:399)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:294)
at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:202)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:393)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
(DefaultArtifactDeployer.java:131)
at
org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
(AbstractDeployStrategy.java:213)
at
org.sonatype.nexus.maven.staging.deploy.strategy.StagingDeployStrategy.finalizeDeploy
(StagingDeployStrategy.java:125)
at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
(DeployMojo.java:213)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126){noformat}
I assume that this is caused by {{preExisting.getPrefix()}} returning null, but
I have no idea why this is happening. Perhaps this is caused by previous
versions not have a goalPrefix set? Shouldn't the implementation handle this
possibility?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAR-310) [regression] Version 3.4.x fails to handle toolchain paths that contain spaces
Gili created MJAR-310:
-
Summary: [regression] Version 3.4.x fails to handle toolchain
paths that contain spaces
Key: MJAR-310
URL: https://issues.apache.org/jira/browse/MJAR-310
Project: Maven JAR Plugin
Issue Type: Bug
Environment: Maven 3.9.6
Windows 10
Reporter: Gili
When upgrading from version 3.3.0 to 3.4.0 I started getting the following
build-time warning:
{{[WARNING] Unrecognized output form C:\Program Files\Java\zulu-8\bin\javac.exe
-version - 'C:\Program' is not recognized as an internal or external command,}}
{{operable program or batch file.}}
The contents of toolchain.xml is:
{{}}
{{}}
{{ }}
{{ jdk}}
{{ }}
{{ 8}}
{{ zulu}}
{{ }}
{{ }}
{{ C:\Program Files\Java\zulu-8}}
{{ }}
{{ }}
{{}}
I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MTOOLCHAINS-54) [regression] Paths with spaces trigger a build-time warning
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845741#comment-17845741
]
Gili commented on MTOOLCHAINS-54:
-
Sorry, please close this issue. The bug seems to be in the JAR plugin.
> [regression] Paths with spaces trigger a build-time warning
> ---
>
> Key: MTOOLCHAINS-54
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-54
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Maven 3.9.6
>Reporter: Gili
>Priority: Major
>
> When upgrading from version 3.1.0 to 3.2.0 I started getting the following
> build-time warning:
>
> {{[WARNING] Unrecognized output form C:\Program
> Files\Java\zulu-8\bin\javac.exe -version - 'C:\Program' is not recognized as
> an internal or external command,}}
> {{operable program or batch file.}}
>
> The contents of toolchain.xml is:
>
> {{}}
> {{}}
> {{ }}
> {{ jdk}}
> {{ }}
> {{ 8}}
> {{ zulu}}
> {{ }}
> {{ }}
> {{ C:\Program Files\Java\zulu-8}}
> {{ }}
> {{ }}
> {{}}
>
> I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MTOOLCHAINS-54) [regression] Paths with spaces trigger a build-time warning
Gili created MTOOLCHAINS-54:
---
Summary: [regression] Paths with spaces trigger a build-time
warning
Key: MTOOLCHAINS-54
URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-54
Project: Maven Toolchains Plugin
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Maven 3.9.6
Reporter: Gili
When upgrading from version 3.1.0 to 3.2.0 I started getting the following
build-time warning:
{{[WARNING] Unrecognized output form C:\Program Files\Java\zulu-8\bin\javac.exe
-version - 'C:\Program' is not recognized as an internal or external command,}}
{{operable program or batch file.}}
The contents of toolchain.xml is:
{{}}
{{}}
{{ }}
{{ jdk}}
{{ }}
{{ 8}}
{{ zulu}}
{{ }}
{{ }}
{{ C:\Program Files\Java\zulu-8}}
{{ }}
{{ }}
{{}}
I don't know if this warning breaks anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-790) The code being documented uses modules but the packages defined in X are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836242#comment-17836242
]
Gili commented on MJAVADOC-790:
---
Please let me know if you are able to reproduce this problem. An easy way to do
so is to run "mvn clean install" on this project:
https://github.com/cowwoc/requirements.java/tree/v9.0.0
> The code being documented uses modules but the packages defined in X are in
> the unnamed module
> --
>
> Key: MJAVADOC-790
> URL: https://issues.apache.org/jira/browse/MJAVADOC-790
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.6.3
> Environment: Microsoft Windows [Version 10.0.19045.4170]
> Maven 3.9.6
> openjdk version "21.0.1" 2023-10-17 LTS
> OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS)
> OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode,
> sharing)
>Reporter: Gili
>Priority: Major
>
> I thought that https://issues.apache.org/jira/browse/MJAVADOC-555 fixed this
> problem, but I have just run into it again.
> Given:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> attach-javadocs
>
> jar
>
>
> public
> Requirements Jackson Plugin ${project.version} API
> Requirements Jackson Plugin ${project.version}
> API
>
>
> --override-methods
> summary
>
>
>
> https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
>
>
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
>${project.basedir}/../java/target/apidocs
>
>
>
> com.github.cowwoc.requirements.jackson.internal,
> com.github.cowwoc.requirements.jackson.internal.*
>
>
>
>
> {code}
> I get this warning:
> {code:java}
> [INFO] --- javadoc:3.6.3:jar (attach-javadocs) @ jackson ---
> [INFO] No previous run data found, generating javadoc.
> [WARNING] Javadoc Warnings
> [WARNING] warning: The code being documented uses modules but the packages
> defined in
> https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
> are in the unnamed module.
> [WARNING] 1 warning {code}
> Any idea why this is happening to Jackson's Javadoc but not to other
> non-modules like Guava?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-790) The code being documented uses modules but the packages defined in X are in the unnamed module
Gili created MJAVADOC-790:
-
Summary: The code being documented uses modules but the packages
defined in X are in the unnamed module
Key: MJAVADOC-790
URL: https://issues.apache.org/jira/browse/MJAVADOC-790
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.6.3
Environment: Microsoft Windows [Version 10.0.19045.4170]
Maven 3.9.6
openjdk version "21.0.1" 2023-10-17 LTS
OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode,
sharing)
Reporter: Gili
I thought that https://issues.apache.org/jira/browse/MJAVADOC-555 fixed this
problem, but I have just run into it again.
Given:
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
attach-javadocs
jar
public
Requirements Jackson Plugin ${project.version} API
Requirements Jackson Plugin ${project.version}
API
--override-methods
summary
https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
${project.basedir}/../java/target/apidocs
com.github.cowwoc.requirements.jackson.internal,
com.github.cowwoc.requirements.jackson.internal.*
{code}
I get this warning:
{code:java}
[INFO] --- javadoc:3.6.3:jar (attach-javadocs) @ jackson ---
[INFO] No previous run data found, generating javadoc.
[WARNING] Javadoc Warnings
[WARNING] warning: The code being documented uses modules but the packages
defined in
https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
are in the unnamed module.
[WARNING] 1 warning {code}
Any idea why this is happening to Jackson's Javadoc but not to other
non-modules like Guava?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
[
https://issues.apache.org/jira/browse/MJAVADOC-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787985#comment-17787985
]
Gili commented on MJAVADOC-560:
---
It's not clear to me which files contain the documentation, so looking at the
pull requests I couldn't tell if this was updated. I saw the Javadoc of some
Mojos getting updated but that's it.
> Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc
> documentation
> ---
>
> Key: MJAVADOC-560
> URL: https://issues.apache.org/jira/browse/MJAVADOC-560
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0
>
>
> Looking at the documentation for javadoc:javadoc at
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I
> see three problems:
> # The documentation lists both *outputDirectory* and *reportOutputDirectory*
> parameters, having the same description. It's not clear what each one is used
> for or what happens if one property is changed without the other.
> # The default value of *outputDirectory* is listed as
> *${project.build.directory}/apidocs* but the value that is actually used is
> *${project.reporting.outputDirectory}/apidocs* (the value of
> *reportOutputDirectory*).
> # It was extremely difficult to find any documentation on
> *${project.reporting.outputDirectory}***, such as what its default value is.
> I eventually found [https://maven.apache.org/pom.html#Reporting] but Google
> does not link directly to this page/section because it doesn't contain an
> explicit reference to *${project.reporting}*.
> Suggested fix(es):
> # Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
> confusion.
> # Update the documentation so it lists the correct default value for
> *outputDirectory*.
> # Link directly from mention of *${project.reporting.outputDirectory}* to
> [https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (SUREFIRE-2206) Downgrade plexus-xml to 3.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2206 ] Gili deleted comment on SUREFIRE-2206: was (Author: cowwoc): Out of curiosity, why was the downgrade necessary? > Downgrade plexus-xml to 3.0.0 > - > > Key: SUREFIRE-2206 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2206 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2206) Downgrade plexus-xml to 3.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784045#comment-17784045 ] Gili commented on SUREFIRE-2206: Out of curiosity, why was the downgrade necessary? > Downgrade plexus-xml to 3.0.0 > - > > Key: SUREFIRE-2206 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2206 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758267#comment-17758267
]
Gili commented on SUREFIRE-2192:
As mentioned, the arg file (which I've attached as
"surefireargs-20230823182041539_3") places gson on the module-path, and I can
confirm that the referenced path exists and seems to be a valid.
I'm unsure on how to proceed further. Please help.
> Module path missing transitive dependency
> -
>
> Key: SUREFIRE-2192
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2192
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 3.1.2
> Environment: Azul JDK 20.0.2
> Microsoft Windows [Version 10.0.19045.3393]
>Reporter: Gili
>Priority: Major
> Attachments: pom.xml, stdout.txt, surefire-20230823182041539_1tmp,
> surefire_0-20230823182041539_2tmp, surefireargs-20230823182041539_3
>
>
> I've got a project with the following dependency tree:
> {code}
> [INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
> [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
> [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
> [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
> [INFO] | +-
> com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
> [INFO] | +-
> com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
> [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
> [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
> [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
> [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
> [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
> [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
> [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
> [INFO] | +- p6spy:p6spy:jar:3.9.1:compile
> [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
> [INFO] | | \-
> com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
> [INFO] | +- org.jooq:jooq:jar:3.18.5:compile
> [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
> [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
> [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
> [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
> [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
> [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
> [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
> [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
> [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
> [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
> [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
> [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
> [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
> [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
> [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
> [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
> [INFO] | | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
> [INFO] | |\-
> org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
> [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
> [INFO] | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
> [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
> [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
> [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
> [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
>
[jira] [Updated] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated SUREFIRE-2192:
---
Attachment: surefire_0-20230823182041539_2tmp
surefire-20230823182041539_1tmp
> Module path missing transitive dependency
> -
>
> Key: SUREFIRE-2192
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2192
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 3.1.2
> Environment: Azul JDK 20.0.2
> Microsoft Windows [Version 10.0.19045.3393]
>Reporter: Gili
>Priority: Major
> Attachments: pom.xml, stdout.txt, surefire-20230823182041539_1tmp,
> surefire_0-20230823182041539_2tmp, surefireargs-20230823182041539_3
>
>
> I've got a project with the following dependency tree:
> {code}
> [INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
> [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
> [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
> [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
> [INFO] | +-
> com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
> [INFO] | +-
> com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
> [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
> [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
> [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
> [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
> [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
> [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
> [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
> [INFO] | +- p6spy:p6spy:jar:3.9.1:compile
> [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
> [INFO] | | \-
> com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
> [INFO] | +- org.jooq:jooq:jar:3.18.5:compile
> [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
> [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
> [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
> [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
> [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
> [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
> [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
> [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
> [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
> [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
> [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
> [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
> [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
> [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
> [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
> [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
> [INFO] | | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
> [INFO] | |\-
> org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
> [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
> [INFO] | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
> [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
> [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
> [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
> [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile
> [INFO] +-
>
[jira] [Updated] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated SUREFIRE-2192:
---
Attachment: surefireargs-20230823182041539_3
> Module path missing transitive dependency
> -
>
> Key: SUREFIRE-2192
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2192
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 3.1.2
> Environment: Azul JDK 20.0.2
> Microsoft Windows [Version 10.0.19045.3393]
>Reporter: Gili
>Priority: Major
> Attachments: pom.xml, stdout.txt, surefire-20230823182041539_1tmp,
> surefire_0-20230823182041539_2tmp, surefireargs-20230823182041539_3
>
>
> I've got a project with the following dependency tree:
> {code}
> [INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
> [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
> [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
> [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
> [INFO] | +-
> com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
> [INFO] | +-
> com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
> [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
> [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
> [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
> [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
> [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
> [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
> [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
> [INFO] | +- p6spy:p6spy:jar:3.9.1:compile
> [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
> [INFO] | | \-
> com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
> [INFO] | +- org.jooq:jooq:jar:3.18.5:compile
> [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
> [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
> [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
> [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
> [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
> [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
> [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
> [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
> [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
> [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
> [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
> [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
> [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
> [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
> [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
> [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
> [INFO] | | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
> [INFO] | |\-
> org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
> [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
> [INFO] | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
> [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
> [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
> [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
> [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile
> [INFO] +-
>
[jira] [Updated] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated SUREFIRE-2192:
---
Attachment: pom.xml
> Module path missing transitive dependency
> -
>
> Key: SUREFIRE-2192
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2192
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 3.1.2
> Environment: Azul JDK 20.0.2
> Microsoft Windows [Version 10.0.19045.3393]
>Reporter: Gili
>Priority: Major
> Attachments: pom.xml, stdout.txt
>
>
> I've got a project with the following dependency tree:
> {code}
> [INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
> [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
> [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
> [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
> [INFO] | +-
> com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
> [INFO] | +-
> com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
> [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
> [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
> [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
> [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
> [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
> [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
> [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
> [INFO] | +- p6spy:p6spy:jar:3.9.1:compile
> [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
> [INFO] | | \-
> com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
> [INFO] | +- org.jooq:jooq:jar:3.18.5:compile
> [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
> [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
> [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
> [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
> [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
> [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
> [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
> [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
> [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
> [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
> [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
> [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
> [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
> [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
> [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
> [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
> [INFO] | | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
> [INFO] | |\-
> org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
> [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
> [INFO] | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
> [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
> [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
> [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
> [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.15.2:compile
> [INFO] +- io.github.classgraph:classgraph:jar:4.8.162:compile
> [INFO] +-
[jira] [Updated] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated SUREFIRE-2192:
---
Attachment: stdout.txt
> Module path missing transitive dependency
> -
>
> Key: SUREFIRE-2192
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2192
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 3.1.2
> Environment: Azul JDK 20.0.2
> Microsoft Windows [Version 10.0.19045.3393]
>Reporter: Gili
>Priority: Major
> Attachments: pom.xml, stdout.txt
>
>
> I've got a project with the following dependency tree:
> {code}
> [INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
> [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
> [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
> [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
> [INFO] | +-
> com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
> [INFO] | +-
> com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
> [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
> [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
> [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
> [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
> [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
> [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
> [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
> [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
> [INFO] | +- p6spy:p6spy:jar:3.9.1:compile
> [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
> [INFO] | | \-
> com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
> [INFO] | +- org.jooq:jooq:jar:3.18.5:compile
> [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
> [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
> [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
> [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
> [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
> [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
> [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
> [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
> [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
> [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
> [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
> [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
> [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
> [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
> [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
> [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
> [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
> [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
> [INFO] | | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
> [INFO] | |\-
> org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
> [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
> [INFO] | \-
> org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
> [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
> [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
> [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
> [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
> [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile
> [INFO] +-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.15.2:compile
> [INFO] +- io.github.classgraph:classgraph:jar:4.8.162:compile
> [INFO] +-
[jira] [Updated] (SUREFIRE-2192) Module path missing transitive dependency
[
https://issues.apache.org/jira/browse/SUREFIRE-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated SUREFIRE-2192:
---
Description:
I've got a project with the following dependency tree:
{code}
[INFO] --- dependency:3.6.0:tree (default-cli) @ server ---
[INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT
[INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile
[INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile
[INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
[INFO] | +-
com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
[INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
[INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
[INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile
[INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile
[INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile
[INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile
[INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile
[INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile
[INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile
[INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile
[INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime
[INFO] | +- p6spy:p6spy:jar:3.9.1:compile
[INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile
[INFO] | | \-
com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile
[INFO] | +- org.jooq:jooq:jar:3.18.5:compile
[INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile
[INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile
[INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile
[INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile
[INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile
[INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile
[INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile
[INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile
[INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile
[INFO] +- com.google.code.gson:gson:jar:2.10.1:compile
[INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile
[INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile
[INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile
[INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile
[INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile
[INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile
[INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile
[INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile
[INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile
[INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile
[INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile
[INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile
[INFO] | | \-
org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile
[INFO] | |\-
org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile
[INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile
[INFO] | \- org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile
[INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile
[INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile
[INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile
[INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile
[INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile
[INFO] +-
com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile
[INFO] +-
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile
[INFO] +-
com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.15.2:compile
[INFO] +- io.github.classgraph:classgraph:jar:4.8.162:compile
[INFO] +- com.github.lalyos:jfiglet:jar:0.0.9:compile
[INFO] +- org.testng:testng:jar:7.8.0:test
[INFO] | +- com.beust:jcommander:jar:1.82:test
[INFO] | \- org.webjars:jquery:jar:3.6.1:test
[INFO] +- io.sentry:sentry:jar:6.28.0:compile
[INFO] +- io.sentry:sentry-logback:jar:6.28.0:compile
[INFO] \- io.sentry:sentry-jdbc:jar:6.28.0:compile
[INFO]
{code}
As you can see, my project depends on flyway which depends on gson.
When I invoke
{code}
System.out.println(ModuleLayer.boot().modules().stream().map(Module::getName).toList());`
{code}
from `main()` I get:
{code}
[jfiglet, org.threeten.extra, org.eclipse.jetty.alpn.client,
[jira] [Created] (SUREFIRE-2192) Module path missing transitive dependency
Gili created SUREFIRE-2192: -- Summary: Module path missing transitive dependency Key: SUREFIRE-2192 URL: https://issues.apache.org/jira/browse/SUREFIRE-2192 Project: Maven Surefire Issue Type: Bug Components: classloading, TestNG support Affects Versions: 3.1.2 Environment: Azul JDK 20.0.2 Microsoft Windows [Version 10.0.19045.3393] Reporter: Gili I've got a project with the following dependency tree: [INFO] --- dependency:3.6.0:tree (default-cli) @ server --- [INFO] gg.soulbound.optimus:server:jar:1.0-SNAPSHOT [INFO] +- gg.soulbound.optimus:common:jar:1.0-SNAPSHOT:compile [INFO] | \- com.google.guava:guava:jar:32.1.2-jre:compile [INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile [INFO] | +- com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile [INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile [INFO] +- gg.soulbound.optimus:requirements-generator:jar:1.0-SNAPSHOT:compile [INFO] | \- com.github.cowwoc.requirements:java:jar:8.0.10:compile [INFO] | +- com.github.cowwoc.requirements:annotations:jar:8.0.10:compile [INFO] | +- com.github.cowwoc.requirements:natives:jar:8.0.10:compile [INFO] | +- io.github.java-diff-utils:java-diff-utils:jar:4.12:compile [INFO] | \- com.github.cowwoc.pouch:core:jar:4.0:compile [INFO] +- gg.soulbound.optimus:database:jar:1.0-SNAPSHOT:compile [INFO] | +- org.postgresql:postgresql:jar:42.6.0:compile [INFO] | | \- org.checkerframework:checker-qual:jar:3.31.0:runtime [INFO] | +- p6spy:p6spy:jar:3.9.1:compile [INFO] | +- org.flywaydb:flyway-core:jar:9.21.2:compile [INFO] | | \- com.fasterxml.jackson.dataformat:jackson-dataformat-toml:jar:2.15.2:compile [INFO] | +- org.jooq:jooq:jar:3.18.5:compile [INFO] | | \- io.r2dbc:r2dbc-spi:jar:1.0.0.RELEASE:compile [INFO] | | \- org.reactivestreams:reactive-streams:jar:1.0.3:compile [INFO] | +- org.jooq:jooq-meta:jar:3.18.5:compile [INFO] | | \- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.0:compile [INFO] | | \- com.sun.activation:jakarta.activation:jar:2.0.0:compile [INFO] | +- gg.soulbound.optimus:jooq-plugin:jar:1.0-SNAPSHOT:compile [INFO] | | \- org.jooq:jooq-codegen:jar:3.18.5:compile [INFO] | +- com.zaxxer:HikariCP:jar:5.0.1:compile [INFO] | \- org.threeten:threeten-extra:jar:1.7.2:compile [INFO] +- com.google.code.gson:gson:jar:2.10.1:compile [INFO] +- gg.soulbound.optimus:domain:jar:1.0-SNAPSHOT:compile [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile [INFO] +- gg.soulbound.optimus:client:jar:1.0-SNAPSHOT:compile [INFO] +- org.eclipse.jetty:jetty-client:jar:12.0.0:compile [INFO] | +- org.eclipse.jetty:jetty-http:jar:12.0.0:compile [INFO] | | \- org.eclipse.jetty:jetty-util:jar:12.0.0:compile [INFO] | +- org.eclipse.jetty:jetty-io:jar:12.0.0:compile [INFO] | \- org.eclipse.jetty:jetty-alpn-client:jar:12.0.0:compile [INFO] +- org.eclipse.jetty.http3:jetty-http3-server:jar:12.0.0:compile [INFO] | +- org.eclipse.jetty:jetty-server:jar:12.0.0:compile [INFO] | +- org.eclipse.jetty.http3:jetty-http3-common:jar:12.0.0:compile [INFO] | | +- org.eclipse.jetty.http3:jetty-http3-qpack:jar:12.0.0:compile [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-common:jar:12.0.0:compile [INFO] | | \- org.eclipse.jetty.quic:jetty-quic-quiche-common:jar:12.0.0:compile [INFO] | |\- org.mortbay.jetty.quiche:jetty-quiche-native:jar:0.16.0:compile [INFO] | \- org.eclipse.jetty.quic:jetty-quic-server:jar:12.0.0:compile [INFO] | \- org.eclipse.jetty.quic:jetty-quic-quiche-jna:jar:12.0.0:compile [INFO] |\- net.java.dev.jna:jna-jpms:jar:5.13.0:compile [INFO] +- org.slf4j:slf4j-api:jar:2.0.7:compile [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.7:compile [INFO] +- ch.qos.logback:logback-classic:jar:1.4.10:compile [INFO] | \- ch.qos.logback:logback-core:jar:1.4.10:compile [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile [INFO] +- com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.15.2:compile [INFO] +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2:compile [INFO] +- com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.15.2:compile [INFO] +- io.github.classgraph:classgraph:jar:4.8.162:compile [INFO] +- com.github.lalyos:jfiglet:jar:0.0.9:compile [INFO] +- org.testng:testng:jar:7.8.0:test [INFO] | +- com.beust:jcommander:jar:1.82:test [INFO] | \- org.webjars:jquery:jar:3.6.1:test [INFO] +- io.sentry:sentry:jar:6.28.0:compile [INFO] +- io.sentry:sentry-logback:jar:6.28.0:compile [INFO] \- io.sentry:sentry-jdbc:jar:6.28.0:compile [INFO] As you can see, my project
[jira] [Created] (MPMD-385) Support for --enable-preview
Gili created MPMD-385: - Summary: Support for --enable-preview Key: MPMD-385 URL: https://issues.apache.org/jira/browse/MPMD-385 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.21.0 Reporter: Gili When running PMD against classes compiled using --enable-preview I get: [WARNING] Error during type resolution of field in class due to: java.lang.UnsupportedClassVersionError: Preview features are not enabled for gg/soulbound/optimus/server/Server (class file version 64.65535). Try running with '--enable-preview' It seems that PMD expects us to pass --enable-preview, but the Maven plugin does not provide a mechanism for doing so. I tried setting targetJdk to "20-preview" but that didn't help either. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-376) localRepository is deprecated
Gili created MPMD-376:
-
Summary: localRepository is deprecated
Key: MPMD-376
URL: https://issues.apache.org/jira/browse/MPMD-376
Project: Maven PMD Plugin
Issue Type: Bug
Reporter: Gili
When running PMD on my project, I get the following warning messages that seem
to be a problem in the Maven Plugin:
PMD 3.20.0
{code:java}
[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid use
of ArtifactRepository type. If you need access to local repository, switch to
'${repositorySystemSession}' expression and get LRM from it instead.
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7682) Ability to send users build-time notes
[ https://issues.apache.org/jira/browse/MNG-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684880#comment-17684880 ] Gili commented on MNG-7682: --- Ah, you're right! I overlooked that. For other users, see [https://stackoverflow.com/a/69233873/14731] for an example. > Ability to send users build-time notes > -- > > Key: MNG-7682 > URL: https://issues.apache.org/jira/browse/MNG-7682 > Project: Maven > Issue Type: New Feature >Reporter: Gili >Priority: Major > > The NPM world has a nice tradition of notifying users when an artifact update > is available, or is the artifact is deprecated, or was moved to a different > coordinate (e.g. when merging with similar libraries). > It would be nice to be able to do the same in Maven somehow. > WORKAROUND: Output runtime warning messages, but this is undesirable because > we want to notify the developer as opposed to the end-user of the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7682) Ability to send users build-time notes
[ https://issues.apache.org/jira/browse/MNG-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684787#comment-17684787 ] Gili commented on MNG-7682: --- Let's leave the issue closed. I wasn't aware of [https://maven.apache.org/guides/mini/guide-relocation.html] when I initially filed this request, and the cost/benefit of the remaining functionality is questionable at this time. Thank you. > Ability to send users build-time notes > -- > > Key: MNG-7682 > URL: https://issues.apache.org/jira/browse/MNG-7682 > Project: Maven > Issue Type: New Feature >Reporter: Gili >Priority: Major > > The NPM world has a nice tradition of notifying users when an artifact update > is available, or is the artifact is deprecated, or was moved to a different > coordinate (e.g. when merging with similar libraries). > It would be nice to be able to do the same in Maven somehow. > WORKAROUND: Output runtime warning messages, but this is undesirable because > we want to notify the developer as opposed to the end-user of the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7682) Ability to send users build-time notes
[ https://issues.apache.org/jira/browse/MNG-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684774#comment-17684774 ] Gili commented on MNG-7682: --- Hi [~michael-o], Could you please clarify how developers are meant to handle notices other than coordinate relocation? Or are you saying that this functionality does not exist, but there are no plans to add it in the future? Thank you. > Ability to send users build-time notes > -- > > Key: MNG-7682 > URL: https://issues.apache.org/jira/browse/MNG-7682 > Project: Maven > Issue Type: New Feature >Reporter: Gili >Priority: Major > > The NPM world has a nice tradition of notifying users when an artifact update > is available, or is the artifact is deprecated, or was moved to a different > coordinate (e.g. when merging with similar libraries). > It would be nice to be able to do the same in Maven somehow. > WORKAROUND: Output runtime warning messages, but this is undesirable because > we want to notify the developer as opposed to the end-user of the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7682) Ability to send users build-time notes
[ https://issues.apache.org/jira/browse/MNG-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684743#comment-17684743 ] Gili commented on MNG-7682: --- Related discussion: [https://maven.apache.org/guides/mini/guide-relocation.html] I say "related" because the existing mechanism does not cover deprecation and other kinds of situations the developer might wish to notify their users about. > Ability to send users build-time notes > -- > > Key: MNG-7682 > URL: https://issues.apache.org/jira/browse/MNG-7682 > Project: Maven > Issue Type: New Feature >Reporter: Gili >Priority: Major > > The NPM world has a nice tradition of notifying users when an artifact update > is available, or is the artifact is deprecated, or was moved to a different > coordinate (e.g. when merging with similar libraries). > It would be nice to be able to do the same in Maven somehow. > WORKAROUND: Output runtime warning messages, but this is undesirable because > we want to notify the developer as opposed to the end-user of the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7682) Ability to send users build-time notes
Gili created MNG-7682: - Summary: Ability to send users build-time notes Key: MNG-7682 URL: https://issues.apache.org/jira/browse/MNG-7682 Project: Maven Issue Type: New Feature Reporter: Gili The NPM world has a nice tradition of notifying users when an artifact update is available, or is the artifact is deprecated, or was moved to a different coordinate (e.g. when merging with similar libraries). It would be nice to be able to do the same in Maven somehow. WORKAROUND: Output runtime warning messages, but this is undesirable because we want to notify the developer as opposed to the end-user of the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:44 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no modules aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:43 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:43 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* class inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Now, anyone in *main* wishing to give *test* access to its internals needs
to give {*}main.internal.SharedSecrets{*}.
# *test* then piggybacks any calls it wants to make through *SharedSecrets* as
outlined in the stackoverflow post.
Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push "bridge functions" into it. It actually works the other way
as well ({*}test{*} can push bridge functions into {*}main{*}) but I've never
needed this to date.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili commented on SUREFIRE-1733:
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* class inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Now, anyone in *main* wishing to give *test* access to its internals needs
to give {*}main.internal.SharedSecrets{*}.
# *test* then piggybacks any calls it wants to make through *SharedSecrets* as
outlined in the stackoverflow post.
Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push "bridge functions" into it. It actually works the other way
as well ({*}test{*} can push bridge functions into {*}main{*}) but I've never
needed this to date.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611915#comment-17611915
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 2:18 PM:
-
Hi Ceki,
What kind of bugs would you be testing for exactly? White-box testing, by
definition, focuses on testing implementation details as opposed to the
business requirements, so I am used to it being used to test private methods.
The only JPMS-specific white-box test that I can think of is ensuring that the
module being tested has access to some other module. And then I wonder why
you'd need to test for this using white-box testing. If this inter-module
access doesn't have any impact that is visible to black-box testing, then
what's the point of testing for it?
Also, you can do any kind of white-box testing you want, from outside the
module, using the SharedSecrets mechanism. This works perfectly, without having
to hack the modules in any way.
was (Author: cowwoc):
Hi Ceki,
What kind of bugs would you be testing for exactly? White-box testing, by
definition, focuses on testing implementation details as opposed to the
business requirements, so I am used to it being used to test orivate methods.
The only JPMS-specific white-box test that I can think of is ensuring that the
module being tested has access to some other module. And then I wonder why
you'd need to test for this using white-box testing. If this inter-module
access doesn't have any impact that is visible to black-box testing, then
what's the point of testing for it?
Also, you can do any kind of white-box testing you want, from outside the
module, using the SharedSecrets mechanism. This works perfectly, without having
to hack the modules in any way.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130)
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611915#comment-17611915
]
Gili commented on SUREFIRE-1733:
Hi Ceki,
What kind of bugs would you be testing for exactly? White-box testing, by
definition, focuses on testing implementation details as opposed to the
business requirements, so I am used to it being used to test orivate methods.
The only JPMS-specific white-box test that I can think of is ensuring that the
module being tested has access to some other module. And then I wonder why
you'd need to test for this using white-box testing. If this inter-module
access doesn't have any impact that is visible to black-box testing, then
what's the point of testing for it?
Also, you can do any kind of white-box testing you want, from outside the
module, using the SharedSecrets mechanism. This works perfectly, without having
to hack the modules in any way.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
>
[jira] [Comment Edited] (MJAVADOC-709) JDK 17 support
[
https://issues.apache.org/jira/browse/MJAVADOC-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519982#comment-17519982
]
Gili edited comment on MJAVADOC-709 at 4/9/22 2:00 PM:
---
Sorry for the false-alarm, you are right. I was mistakenly running
JDK17-specific configuration using a JDK11 runtime.
You can close this issue.
was (Author: cowwoc):
Sorry for the false-alarm, you are right. I was mistakenly running
JDK17-specific configuration using a JDK11 runtime.
> JDK 17 support
> --
>
> Key: MJAVADOC-709
> URL: https://issues.apache.org/jira/browse/MJAVADOC-709
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.2
>Reporter: Gili
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal
> I get the following error:
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 61.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:37)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:90)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:38)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:364)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:135)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5232)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2213)
> at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
> (JavadocJar.java:189)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:2041)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
> Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-709) JDK 17 support
[
https://issues.apache.org/jira/browse/MJAVADOC-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517164#comment-17517164
]
Gili commented on MJAVADOC-709:
---
Related to https://github.com/codehaus-plexus/plexus-languages/issues/120
> JDK 17 support
> --
>
> Key: MJAVADOC-709
> URL: https://issues.apache.org/jira/browse/MJAVADOC-709
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.2
>Reporter: Gili
>Priority: Blocker
>
> The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal
> I get the following error:
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 61.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:37)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:90)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:38)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:364)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:135)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5232)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2213)
> at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
> (JavadocJar.java:189)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:2041)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
> Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MJAVADOC-709) JDK 17 support
Gili created MJAVADOC-709:
-
Summary: JDK 17 support
Key: MJAVADOC-709
URL: https://issues.apache.org/jira/browse/MJAVADOC-709
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.3.2
Reporter: Gili
The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal I
get the following error:
{code:java}
Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
major.minor version 61.0
at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
(ModuleInfo.java:1091)
at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
(BinaryModuleInfoParser.java:37)
at
org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
(AbstractBinaryModuleInfoParser.java:90)
at
org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
(AbstractBinaryModuleInfoParser.java:38)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:364)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:135)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
(AbstractJavadocMojo.java:5232)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2213)
at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
(JavadocJar.java:189)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
(AbstractJavadocMojo.java:2041)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-367) Plugin should output information needed to suppress Xlint warnings
[ https://issues.apache.org/jira/browse/MCOMPILER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487729#comment-17487729 ] Gili commented on MCOMPILER-367: Filed [https://github.com/codehaus-plexus/plexus-compiler/issues/183] Feel free to add your comments. > Plugin should output information needed to suppress Xlint warnings > -- > > Key: MCOMPILER-367 > URL: https://issues.apache.org/jira/browse/MCOMPILER-367 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.0 >Reporter: Gili >Priority: Major > Attachments: testcase.zip > > > I will attach a testcase showing the following problem. > If you compile a project that has compiler warnings, javac's output indicates > which Xlint option will suppress the warning. But when compiling the same > code under this plugin, this vital information is suppressed so the user has > a difficult time figuring out which option to use. > Expected behavior: output should indicate which Xlint option corresponds to > the warning. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477372#comment-17477372
]
Gili commented on MJAVADOC-704:
---
Good catch! Upgrading to JDK 11.0.13 fixed the problem. Sorry for the false
alarm. You can close this issue.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476980#comment-17476980
]
Gili commented on MJAVADOC-704:
---
As a workaround, I've added {{jdkToolchain.version=8}} where necessary and ran
the build using JDK 17 instead. Now the build runs to completion.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476960#comment-17476960
]
Gili edited comment on MJAVADOC-704 at 1/17/22, 5:19 AM:
-
The error {{module not found: org.slf4j}} was caused by
[https://bugs.openjdk.java.net/browse/JDK-8208269.|https://bugs.openjdk.java.net/browse/JDK-8208269,]
Building using JDK 17 fixed that problem.
The original question remains: why am I getting a different result when
building using JDK 8 versus 17? I am expecting {{jdkToolchain.version=17}} to
cause JDK 17's javadoc tool to get used, but it does not seem to.
was (Author: cowwoc):
The error {{module not found: org.slf4j}} was caused by
[https://bugs.openjdk.java.net/browse/JDK-8208269.|https://bugs.openjdk.java.net/browse/JDK-8208269,]
Building using JDK 17 fixed that problem.
The original question remains: why am I getting a different result when
building using JDK 8 versus 17? I am expecting {{jdkToolchains.version=17 }}to
cause JDK 17's javadoc tool to get used, but it does not seem to.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476960#comment-17476960
]
Gili commented on MJAVADOC-704:
---
The error {{module not found: org.slf4j}} was caused by
[https://bugs.openjdk.java.net/browse/JDK-8208269.|https://bugs.openjdk.java.net/browse/JDK-8208269,]
Building using JDK 17 fixed that problem.
The original question remains: why am I getting a different result when
building using JDK 8 versus 17? I am expecting {{jdkToolchains.version=17 }}to
cause JDK 17's javadoc tool to get used, but it does not seem to.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
Gili created MJAVADOC-704:
-
Summary: Javadoc plugin does not respect jdkToolchain
Key: MJAVADOC-704
URL: https://issues.apache.org/jira/browse/MJAVADOC-704
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.3.1
Reporter: Gili
If I run the following using JDK 8:
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
3.3.1
attach-javadocs
jar
11
{code}
I get:
{code:java}
[INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program Files\Java\jdk-11.0.2]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
project core: Execution attach-javadocs of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
[...]
Caused by: java.lang.UnsupportedOperationException
at
org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
(CmdModuleNameExtractor.java:46){code}
If I run the same code using JDK 11 I get past this point (I get an error
relating to the contents of module-info):
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
project core: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 -
C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
module not found: org.slf4j
[ERROR] requires org.slf4j;
[ERROR] ^
[ERROR]
[ERROR] Command line was: cmd.exe /X /C ""C:\Program
Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
[ERROR]
[ERROR] -> [Help 1] {code}
This seems to imply that {{jdkToolchain}} is being ignored.
On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin it
seems to work just fine. My toolchains.xml file contains:
{code:java}
jdk
11
oracle
C:\Program Files\Java\jdk-11.0.2
{code}
Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-269) Ability to replace also target/classes with modified classes
[ https://issues.apache.org/jira/browse/MSHADE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449908#comment-17449908 ] Gili commented on MSHADE-269: - [~clebertsuconic] So what you're saying is that shaded JARs cannot be tested by the same project that packages it. So integration tests fly out the window, not to mention any other sort of inter-module dependency. Something doesn't make sense here. > Ability to replace also target/classes with modified classes > > > Key: MSHADE-269 > URL: https://issues.apache.org/jira/browse/MSHADE-269 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Ivan Balashov >Priority: Major > > Relocated classes are only included into artifact jar bypassing module's > target / classes directory. IDEs pick up unmodified classes which is > undesirable. > Following the corresponding Intellij Idea Issue: > [https://youtrack.jetbrains.com/issue/IDEA-93855] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-269) Ability to replace also target/classes with modified classes
[ https://issues.apache.org/jira/browse/MSHADE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446907#comment-17446907 ] Gili commented on MSHADE-269: - [~clebertsuconic] I don't understand. You wrote: > creating this sort of dependencies between projects will probably cause more > harm than good. What sort of dependencies? When someone builds a project, and it uses shade to rewrite its own JAR then I believe this issue is asking to rewrite target/classes as well. We are not talking about rewriting other projects but rather our own. So what "dependencies between projects" are we creating that don't already exist? > Ability to replace also target/classes with modified classes > > > Key: MSHADE-269 > URL: https://issues.apache.org/jira/browse/MSHADE-269 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Ivan Balashov >Priority: Major > > Relocated classes are only included into artifact jar bypassing module's > target / classes directory. IDEs pick up unmodified classes which is > undesirable. > Following the corresponding Intellij Idea Issue: > [https://youtrack.jetbrains.com/issue/IDEA-93855] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MJAVADOC-698) javadoc:javadoc fails for non-JPMS mojo
[
https://issues.apache.org/jira/browse/MJAVADOC-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440213#comment-17440213
]
Gili commented on MJAVADOC-698:
---
I'm not sure why this didn't break in past releases but I don't think it's a
bug in the plugin implementation. If anything, I suggest adding documentation
for this use-case.
I had to add the following configuration to the javadoc plugin configuration:
{code:java}
--add-modules
java.xml
{code}
In other words, the javadoc tool expects us to give it Java Modules but Mojos
cannot be a full-fledged module. Instead, we need to compile it as an
automatic-module and pass {{--add-modules}} to the Javadoc plugin to resolve
any missing module-info related dependencies.
I hope this helps others.
> javadoc:javadoc fails for non-JPMS mojo
> ---
>
> Key: MJAVADOC-698
> URL: https://issues.apache.org/jira/browse/MJAVADOC-698
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> I upgraded maven-javadoc-plugin from version 3.2.0 to 3.3.1. At the same
> time, I upgraded from JDK 11 to 17. All of a sudden I am getting the
> following build failure I was not getting before:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven_plugin: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\AbstractGeneratorMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\GenerateApiMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\OptimizeExceptionsMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\package-info.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\UnpackMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java...
> [ERROR] Loading source files for package
> com.github.cowwoc.requirements.maven...
> [ERROR] Constructing Javadoc information...
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:8:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Document;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:9:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Element;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:10:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Node;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:11:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.NodeList;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:12:
> error: package org.xml.sax is not visible
> [ERROR] import org.xml.sax.SAXException;
> [ERROR] ^
> [ERROR] (package org.xml.sax is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:14:
> error: package javax.xml.parsers is not
[jira] [Updated] (MJAVADOC-698) javadoc:javadoc fails for non-JPMS mojo
[
https://issues.apache.org/jira/browse/MJAVADOC-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-698:
--
Description:
I upgraded maven-javadoc-plugin from version 3.2.0 to 3.3.1. At the same time,
I upgraded from JDK 11 to 17. All of a sudden I am getting the following build
failure I was not getting before:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
project maven_plugin: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\AbstractGeneratorMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\GenerateApiMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\OptimizeExceptionsMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\package-info.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\UnpackMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java...
[ERROR] Loading source files for package com.github.cowwoc.requirements.maven...
[ERROR] Constructing Javadoc information...
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:8:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Document;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:9:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Element;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:10:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Node;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:11:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.NodeList;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:12:
error: package org.xml.sax is not visible
[ERROR] import org.xml.sax.SAXException;
[ERROR] ^
[ERROR] (package org.xml.sax is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:14:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.DocumentBuilder;
[ERROR] ^
[ERROR] (package javax.xml.parsers is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:15:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.DocumentBuilderFactory;
[ERROR] ^
[ERROR] (package javax.xml.parsers is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:16:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.ParserConfigurationException;
[ERROR] ^
[ERROR] (package javax.xml.parsers is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR] 8 errors
[ERROR]
[ERROR] Command line was:
[jira] [Created] (MJAVADOC-698) javadoc:javadoc fails for non-JPMS mojo
Gili created MJAVADOC-698:
-
Summary: javadoc:javadoc fails for non-JPMS mojo
Key: MJAVADOC-698
URL: https://issues.apache.org/jira/browse/MJAVADOC-698
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.3.1
Reporter: Gili
I upgraded maven-javadoc-plugin from version 3.2.0 to 3.3.1. At the same time,
I upgraded from JDK 11 to 17. All of a sudden I am getting the following build
failure I was not getting before:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
project maven_plugin: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\AbstractGeneratorMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\GenerateApiMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\OptimizeExceptionsMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\package-info.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\UnpackMojo.java...
[ERROR] Loading source file
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java...
[ERROR] Loading source files for package com.github.cowwoc.requirements.maven...
[ERROR] Constructing Javadoc information...
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:8:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Document;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:9:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Element;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:10:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.Node;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:11:
error: package org.w3c.dom is not visible
[ERROR] import org.w3c.dom.NodeList;
[ERROR] ^
[ERROR] (package org.w3c.dom is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:12:
error: package org.xml.sax is not visible
[ERROR] import org.xml.sax.SAXException;
[ERROR] ^
[ERROR] (package org.xml.sax is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:14:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.DocumentBuilder;
[ERROR] ^
[ERROR] (package javax.xml.parsers is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:15:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.DocumentBuilderFactory;
[ERROR] ^
[ERROR] (package javax.xml.parsers is declared in module java.xml, but module
com.github.cowwoc.requirements.maven_plugin does not read it)
[ERROR]
C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:16:
error: package javax.xml.parsers is not visible
[ERROR] import javax.xml.parsers.ParserConfigurationException;
[ERROR] ^
[ERROR] (package
[jira] [Commented] (MCOMPILER-437) Clarify how to use --patch-module
[ https://issues.apache.org/jira/browse/MCOMPILER-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411702#comment-17411702 ] Gili commented on MCOMPILER-437: Let's close this issue. I don't remember what this was about. > Clarify how to use --patch-module > - > > Key: MCOMPILER-437 > URL: https://issues.apache.org/jira/browse/MCOMPILER-437 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > > https://maven.apache.org/plugins/maven-compiler-plugin/examples/jpms_args.html > says that the --patch-module syntax is: > --patch-module =(, )* > But I am unable to get it to work. I always get "Can't locate X". > I couldn't find any integration tests or other example code showing how to > get this to work when the right hand side is meant to be a JAR file. > I am trying to work around split packages in org.apache.sshd:ssh-common and > org.apache.sshd:ssh-core by declaring a single module org.apache.sshd.core > that is meant to contain a merge of the two JAR files. How can I make this > work? > Consider augmenting the documentation and/or adding an integration test to > make this use-case more obvious. Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-417) Document compileSourceRoots, multiReleaseOutput
[
https://issues.apache.org/jira/browse/MCOMPILER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411481#comment-17411481
]
Gili commented on MCOMPILER-417:
The "Single Project" heading links to
[https://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/]
Is there any way to get that document to use {{multiReleaseOutput}} in place of
{{maven-antrun-plugin }}and {{maven-resources-plugin}} as it does now?
> Document compileSourceRoots, multiReleaseOutput
> ---
>
> Key: MCOMPILER-417
> URL: https://issues.apache.org/jira/browse/MCOMPILER-417
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
>
> Please update
> [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html]
> and
> [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html]
> to mention the "compileSourceRoots", "multiReleaseOutput" parameters as well
> as providing an example like
> [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108]
> in the usage section. It is an excellent solution that (seems to) work a lot
> cleaner than the other approaches.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-417) Document compileSourceRoots, multiReleaseOutput
[
https://issues.apache.org/jira/browse/MCOMPILER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411481#comment-17411481
]
Gili edited comment on MCOMPILER-417 at 9/7/21, 8:53 PM:
-
The "Single Project" heading links to
[https://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/]
Is there any way to get that document to use {{multiReleaseOutput}} in place of
{{maven-antrun-plugin}} and {{maven-resources-plugin}} as it does now?
was (Author: cowwoc):
The "Single Project" heading links to
[https://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/]
Is there any way to get that document to use {{multiReleaseOutput}} in place of
{{maven-antrun-plugin }}and {{maven-resources-plugin}} as it does now?
> Document compileSourceRoots, multiReleaseOutput
> ---
>
> Key: MCOMPILER-417
> URL: https://issues.apache.org/jira/browse/MCOMPILER-417
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
>
> Please update
> [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html]
> and
> [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html]
> to mention the "compileSourceRoots", "multiReleaseOutput" parameters as well
> as providing an example like
> [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108]
> in the usage section. It is an excellent solution that (seems to) work a lot
> cleaner than the other approaches.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-417) Document compileSourceRoots, multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411453#comment-17411453 ] Gili commented on MCOMPILER-417: I understand, but I looked at the example code provided for each pattern and I didn't see any of them using the aforementioned code snippet. Did I miss anything? Or is this pattern missing from the list? > Document compileSourceRoots, multiReleaseOutput > --- > > Key: MCOMPILER-417 > URL: https://issues.apache.org/jira/browse/MCOMPILER-417 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Assignee: Robert Scholte >Priority: Major > > Please update > [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html] > and > [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html] > to mention the "compileSourceRoots", "multiReleaseOutput" parameters as well > as providing an example like > [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108] > in the usage section. It is an excellent solution that (seems to) work a lot > cleaner than the other approaches. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-417) Document compileSourceRoots, multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411433#comment-17411433 ] Gili commented on MCOMPILER-417: Where? I checked all the links coming off that page and the only mention of it I saw was in the integration tests (last link of the entire page). I don't think many users will find it buried in there. > Document compileSourceRoots, multiReleaseOutput > --- > > Key: MCOMPILER-417 > URL: https://issues.apache.org/jira/browse/MCOMPILER-417 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Assignee: Robert Scholte >Priority: Major > > Please update > [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html] > and > [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html] > to mention the "compileSourceRoots", "multiReleaseOutput" parameters as well > as providing an example like > [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108] > in the usage section. It is an excellent solution that (seems to) work a lot > cleaner than the other approaches. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-417) Document compileSourceRoots, multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411395#comment-17411395 ] Gili commented on MCOMPILER-417: Why doesn't [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html] mention "multiReleaseOutput"? > Document compileSourceRoots, multiReleaseOutput > --- > > Key: MCOMPILER-417 > URL: https://issues.apache.org/jira/browse/MCOMPILER-417 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Assignee: Robert Scholte >Priority: Major > > Please update > [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html] > and > [https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html] > to mention the "compileSourceRoots", "multiReleaseOutput" parameters as well > as providing an example like > [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108] > in the usage section. It is an excellent solution that (seems to) work a lot > cleaner than the other approaches. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215649#comment-17215649 ] Gili commented on MCOMPILER-436: Got it. So let's leave things as-is. For future reference (in case someone else runs across this issue) it looks like this logic is happening at https://github.com/codehaus-plexus/plexus-languages/blob/15031cc226516d0fa30a43aa38d8159e6e2e9115/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L201 which invokes https://github.com/codehaus-plexus/plexus-languages/blob/15031cc226516d0fa30a43aa38d8159e6e2e9115/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L357 which invokes https://github.com/codehaus-plexus/plexus-languages/blob/dc2d4d45edb7b63de7575fe10bd2af4a6b577e4b/plexus-java/src/main/java9/org/codehaus/plexus/languages/java/jpms/CmdModuleNameExtractor.java#L90 > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215505#comment-17215505 ] Gili commented on MCOMPILER-436: Looking at https://github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java it seems that the module name *can* be extracted. The problem is that LocationManager.resolvePaths() does a lot more than extracting the module name. It tries resolving all line entries inside module-info.java. If we were to tease apart the different functionality, what would happen? Would we get past the module name extraction but at runtime the JRE would fail with a module load error? From a user perspective I think this would be a much nicer experience. I just don't know how much extra work will be involved to make this happen. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215209#comment-17215209 ] Gili commented on MCOMPILER-436: [~rfscholte] I see your point but I still feel that the error message is missing an important line of reasoning. >From the perspective of someone who is not familiar with the implementation >details of Java Modules, one would think that you should be able to extract >the module name for the aforementioned case. I mean, there is a well-defined >algorithm for converting the filenames into automatic module names. There is >also an Automatic-Module-Name entry in the manifest file. So from the user's >perspective you have everything you need to extract a module name. What the error message fails to explain is that although we can theoretically extract a module name, we can't in fact load the JAR file as a module. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHADE-380) Improve FAQ for multiple runs of plugin
Gili created MSHADE-380:
---
Summary: Improve FAQ for multiple runs of plugin
Key: MSHADE-380
URL: https://issues.apache.org/jira/browse/MSHADE-380
Project: Maven Shade Plugin
Issue Type: Improvement
Reporter: Gili
https://issues.apache.org/jira/browse/MSHADE-85 provides a vague recommendation
to alter the output name to avoid a second run of the plugin from using the
output of the first run as input. In practice this is a bad workaround because
if you do this then maven-install-plugin ends up installing the non-shaded JAR
file.
A much easier and cleaner solution is to set the property of
the jar plugin as follows:
{code:java}
org.apache.maven.plugins
maven-jar-plugin
default-jar
true
{code}
Please update the recommendations in the FAQ with the above suggestion. Please
include the full code snippet to avoid any misunderstanding.
Bigger picture, the default behavior is bad. All maven plugins work properly by
default across multiple runs. This plugin does not. What prevents you from
leaving the output as foobar-shaded.jar and somehow hinting to the
maven-install-plugin to use that as input instead? I don't know the exact
implementation details, but certainly the happy path should work out of the box
without users needing to jump through any hoops.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214948#comment-17214948
]
Gili edited comment on MCOMPILER-436 at 10/15/20, 7:35 PM:
---
[~rfscholte] I get:
{quote}InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
{quote}
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load :
"
was (Author: cowwoc):
[~rfscholte] I get:
bq. InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load {filename}:
{exception.getMessage()}"
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214948#comment-17214948
]
Gili commented on MCOMPILER-436:
[~rfscholte] I get:
bq. InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load {filename}:
{exception.getMessage()}"
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214854#comment-17214854 ] Gili commented on MCOMPILER-436: Hi Robert, 1. It sounds to me like the plugin should be able to extract a module name from the JAR file even if later on that module cannot be used due to the split package issue. Therefore the first message is misleading and should be corrected. 2. Is it really illegal for a Java Module to reference a service contained in an external module? Assuming both are legal modules (no split package) this should work, right? 3. Can we improve the error message to mention that "although can be used on the classpath, it cannot be loaded on the module path due to split package found in both and "? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214787#comment-17214787 ] Gili edited comment on MCOMPILER-436 at 10/15/20, 3:42 PM: --- [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. The corresponding bug report is https://issues.apache.org/jira/projects/SSHD/issues/SSHD-1091 That said, the following error message seems like an issue with the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? was (Author: cowwoc): [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. That said, the following error message seems like an issue in the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214787#comment-17214787 ] Gili commented on MCOMPILER-436: [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. That said, the following error message seems like an issue in the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212754#comment-17212754 ] Gili commented on SUREFIRE-1853: Fixed by https://github.com/apache/maven-surefire/pull/322/ > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212607#comment-17212607 ] Gili commented on MCOMPILER-436: The hardest problem to solve is the split packages. The most straightforward way would be to assign each artifact a unique package (e.g. move all packages of sshd-core under org.apache.sshd.core, all packages of sshd-common under org.apache.sshd.common and so on) but this will break backwards compatibility. Another approach would be to merge any artifacts that split a package. This would retain the same package names but the artifacts would change (this would be a lesser breakage of backwards compatibility but might reduce the modularity of the library). There are many possibilities. Once you decide which way you want to proceed, we can move forward. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212166#comment-17212166 ] Gili edited comment on MCOMPILER-436 at 10/12/20, 7:04 AM: --- I've lost 5 hours of my life to this issue. I tried: * Adding Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * Using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. was (Author: cowwoc): I've lost 5 hours of my life to this issue. I've tried: * I added Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * I tried using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212166#comment-17212166 ] Gili commented on MCOMPILER-436: I've lost 5 hours of my life to this issue. I've tried: * I added Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * I tried using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-437) Clarify how to use --patch-module
[ https://issues.apache.org/jira/browse/MCOMPILER-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212138#comment-17212138 ] Gili commented on MCOMPILER-437: Per https://issues.apache.org/jira/browse/MCOMPILER-311?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel the documentation seems to be incorrect. The correct syntax is --patch-module=org.apache.sshd.core=sshd-common-2.6.0-SNAPSHOT.jar, sshd-core-2.6.0-SNAPSHOT.jar not: --patch-module org.apache.sshd.core=sshd-common-2.6.0-SNAPSHOT.jar, sshd-core-2.6.0-SNAPSHOT.jar So I am no longer getting the "Can't locate X" error. That said, the resulting module still does not work as expected: package org.apache.sshd.client.config.keys is not visible (package org.apache.sshd.client.config.keys is declared in the unnamed module, but module myapplication does not read it) I expected this to work because my application's module-info.java contains "requires org.apache.sshd.core". The package in question should be coming from the sshd-common JAR file, not from the unnamed module. > Clarify how to use --patch-module > - > > Key: MCOMPILER-437 > URL: https://issues.apache.org/jira/browse/MCOMPILER-437 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > > https://maven.apache.org/plugins/maven-compiler-plugin/examples/jpms_args.html > says that the --patch-module syntax is: > --patch-module =(, )* > But I am unable to get it to work. I always get "Can't locate X". > I couldn't find any integration tests or other example code showing how to > get this to work when the right hand side is meant to be a JAR file. > I am trying to work around split packages in org.apache.sshd:ssh-common and > org.apache.sshd:ssh-core by declaring a single module org.apache.sshd.core > that is meant to contain a merge of the two JAR files. How can I make this > work? > Consider augmenting the documentation and/or adding an integration test to > make this use-case more obvious. Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-437) Clarify how to use --patch-module
[ https://issues.apache.org/jira/browse/MCOMPILER-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MCOMPILER-437: --- Affects Version/s: 3.8.1 > Clarify how to use --patch-module > - > > Key: MCOMPILER-437 > URL: https://issues.apache.org/jira/browse/MCOMPILER-437 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > > https://maven.apache.org/plugins/maven-compiler-plugin/examples/jpms_args.html > says that the --patch-module syntax is: > --patch-module =(, )* > But I am unable to get it to work. I always get "Can't locate X". > I couldn't find any integration tests or other example code showing how to > get this to work when the right hand side is meant to be a JAR file. > I am trying to work around split packages in org.apache.sshd:ssh-common and > org.apache.sshd:ssh-core by declaring a single module org.apache.sshd.core > that is meant to contain a merge of the two JAR files. How can I make this > work? > Consider augmenting the documentation and/or adding an integration test to > make this use-case more obvious. Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCOMPILER-437) Clarify how to use --patch-module
Gili created MCOMPILER-437: -- Summary: Clarify how to use --patch-module Key: MCOMPILER-437 URL: https://issues.apache.org/jira/browse/MCOMPILER-437 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Gili https://maven.apache.org/plugins/maven-compiler-plugin/examples/jpms_args.html says that the --patch-module syntax is: --patch-module =(, )* But I am unable to get it to work. I always get "Can't locate X". I couldn't find any integration tests or other example code showing how to get this to work when the right hand side is meant to be a JAR file. I am trying to work around split packages in org.apache.sshd:ssh-common and org.apache.sshd:ssh-core by declaring a single module org.apache.sshd.core that is meant to contain a merge of the two JAR files. How can I make this work? Consider augmenting the documentation and/or adding an integration test to make this use-case more obvious. Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
Gili created MCOMPILER-436: -- Summary: Cannot compile code that depends on on Apache Mina SSH due to JPMS error Key: MCOMPILER-436 URL: https://issues.apache.org/jira/browse/MCOMPILER-436 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.8.1 Reporter: Gili Attachments: extract-module-name.zip 1. Extract Testcase 2. Run "mvn clean install" 3. Build fails with: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core Expected behavior: The plugin should be able to extract the module name given that sshd-core depends on sshd-commons which contains the aforementioned provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212038#comment-17212038 ] Gili commented on SUREFIRE-1853: Looking at the code, it sounds like the only change that is needed is to prefix the documentation with "When set to false," The full sentence would read "When set to false, disables modular path (aka Jigsaw project since of Java 9) even if module-info.java is used in project." The rest of the paragraph sounds good as-is. > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated SUREFIRE-1853: --- Summary: Clarify useModulePath documentation (was: Clarify useModulePath option) > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1853) Clarify useModulePath option
Gili created SUREFIRE-1853: -- Summary: Clarify useModulePath option Key: SUREFIRE-1853 URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 Project: Maven Surefire Issue Type: Improvement Reporter: Gili https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states that useModulePath disables the use of the module path. This contradicts the option name which implies that a value of true *enables* the use of module path. Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161363#comment-17161363
]
Gili commented on SUREFIRE-1811:
Is ClassGraph being loaded on the modulepath or classpath? You say it can see
the module, but that's not the same thing as saying it can find resources
inside that module. Can you prove that ClassGraph can see and open the contents
of the resource file when loaded on the modulepath?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"
[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097465#comment-17097465
]
Gili edited comment on SUREFIRE-1563 at 7/8/20, 9:45 PM:
-
[~rfscholte] Assuming I understand you correctly, I believe we have the same
requirements. So let me throw the following proposal on the table:
Use-cases:
1. Blackbox testing:
* Users are expected to provide {{src/test/java/module-info.java}} which
"requires" the main module.
* Maven compiles this as-is (without merging the main and test {{module-info}}
files).
* Surefire uses the test {{module-info.java}} without modification.
2. Whitebox testing:
* Option A: Users provide {{src/test/java/module-info.java}} which works like
the blackbox testing case, then use the SharedSecrets mechanism
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access
internal members.
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with
module-info that is a merge between the main and test module-info files.
3. requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in
{{module-info.java}} and automatically fire off the desired command-line
options on behalf of the user? Does the user need to specify anything for
correct execution or do we have sufficient information?
I prefer Option 2A but I appreciate that it involves a lot more work for users
than Option 2B. I'm open to new ideas as well.
So, which points do we all agree on (so we can take them off the table) before
moving on to the points of contention?
was (Author: cowwoc):
[~rfscholte] Assuming I understand you correctly, I believe we have the same
requirements. So let me throw the following proposal on the table:
Use-cases:
1. Blackbox testing:
* Users are expected to provide {{src/test/java/module-info.java}} which
"requires" the main module.
* Maven compiles this as-is (No merging against the main {{module-info) }}into
target/test-classes.
* Surefire uses this {{module-info}} without modification.
2. Whitebox testing:
* Option A: Users provide {{src/test/java/module-info.java}} which works like
the blackbox testing case, then use the SharedSecrets mechanism
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access
internal members.
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with
module-info that is a merge between the main and test module-info files.
3. requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in
{{module-info.java}} and automatically fire off the desired command-line
options on behalf of the user? Does the user need to specify anything for
correct execution or do we have sufficient information?
I prefer Option 2A but I appreciate that it involves a lot more work for users
than Option 2B. I'm open to new ideas as well.
So, which points do we all agree on (so we can take them off the table) before
moving on to the points of contention?
> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the
> tests run fine.
> Attached a reproducible project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"
[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097465#comment-17097465
]
Gili edited comment on SUREFIRE-1563 at 7/8/20, 9:42 PM:
-
[~rfscholte] Assuming I understand you correctly, I believe we have the same
requirements. So let me throw the following proposal on the table:
Use-cases:
1. Blackbox testing:
* Users are expected to provide {{src/test/java/module-info.java}} which
"requires" the main module.
* Maven compiles this as-is (No merging against the main {{module-info) }}into
target/test-classes.
* Surefire uses this {{module-info}} without modification.
2. Whitebox testing:
* Option A: Users provide {{src/test/java/module-info.java}} which works like
the blackbox testing case, then use the SharedSecrets mechanism
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access
internal members.
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with
module-info that is a merge between the main and test module-info files.
3. requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in
{{module-info.java}} and automatically fire off the desired command-line
options on behalf of the user? Does the user need to specify anything for
correct execution or do we have sufficient information?
I prefer Option 2A but I appreciate that it involves a lot more work for users
than Option 2B. I'm open to new ideas as well.
So, which points do we all agree on (so we can take them off the table) before
moving on to the points of contention?
was (Author: cowwoc):
[~rfscholte] Assuming I understand you correctly, I believe we have the same
requirements. So let me throw the following proposal on the table:
Use-cases:
1. Blackbox testing:
* Users are expected to provide {{src/test/java/module-info.java}} which
"requires" the main module.
* Maven compiles this as-is (No merging against the main {{module-info) }}into
target/test-classes.
* Surefire uses this {{module-info}} without modification.
2. Whitebox testing:
* Option A: Users provide {{src/test/java/module-info.java}} which works like
the blackbox testing case, then use the SharedSecrets mechanism
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access
internal members.
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with
module-info that is a join between the main and test module-info files.
3. requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in
{{module-info.java}} and automatically fire off the desired command-line
options on behalf of the user? Does the user need to specify anything for
correct execution or do we have sufficient information?
I prefer Option 2A but I appreciate that it involves a lot more work for users
than Option 2B. I'm open to new ideas as well.
So, which points do we all agree on (so we can take them off the table) before
moving on to the points of contention?
> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the
> tests run fine.
> Attached a reproducible project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154027#comment-17154027
]
Gili commented on SUREFIRE-1811:
[~Pavel_K] Okay, so if I understand you correctly nothing is blocking you from
running white-box unit tests on the classpath.
Let's circle back. My understanding is that the original issue you reported was
caused by user error and is no longer relevant.
Subsequent discussion about merging module-info.java files (option 3.2) is
already covered by SUREFIRE-1563 (which remains open). Consequently, can we
close this Jira issue?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153762#comment-17153762
]
Gili commented on SUREFIRE-1811:
[~Pavel_K] Thank you for providing that module-info snipplet. This helps
discussing concrete solutions.
Per
[https://junit.org/junit5/docs/current/user-guide/#launcher-api-listeners-custom]
the correct way for classpath projects to register an execution listener is
using {{/META-INF/services/org.junit.platform.launcher.TestExecutionListener}}.
So you should be good to go.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153763#comment-17153763
]
Gili commented on SUREFIRE-1811:
[~sor] My apologies. I think you're right.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153727#comment-17153727
]
Gili commented on SUREFIRE-1811:
[~Pavel_K]
# This is a subjective statement. Don't get me wrong. I personally advocate to
use JPMS everywhere humanly possible but objectively-speaking JPMS is only
relevant in the context of someone consuming your module. If no one is
consuming your module then "it would be nice" to use JPMS but in the face of
problems you are far better off simply not using it.
# Covered by point 1.
# Let's be concrete. What are the advantages of JPMS-enabled unit tests?
# I don't question the need for white-box unit tests to access private APIs in
the main module but as I mentioned to Christian, you can only discuss concrete
testcases because otherwise this discussion will go on forever.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153721#comment-17153721
]
Gili commented on SUREFIRE-1811:
[~sor] I can't find the relevant quote at the moment but I remember
[~rfscholte] saying that the --patch-module command-line was added at his
request but later on they found a way to make Maven work without it. I'm not
convinced that is actually required in this case but it would certainly help to
have a concrete testcase (with full source-code) for us to look at to settle
this discussion. We could go around and around forever when discussing things
in the abstract.
Also, please note that the referenced use-case is totally different from
anything we've touched upon before. Pavel wants to add "exports" to the main
module when running unit tests. In the discussion thread, they are talking
about adding "requires" when running unit tests. Something sounds very wrong
there. Let's get a concrete testcase and then we can discuss this further.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153652#comment-17153652
]
Gili commented on SUREFIRE-1811:
> You can't omit it because it will become non jpms module.
And why is this a problem? The point of making *blackbox* unit tests a JPMS
module is that they can ensure that your main module does not expose any
secrets to the outside world. The same is not true for *whitebox* unit tests.
Why insist on module-info.java for such tests?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153640#comment-17153640
]
Gili edited comment on SUREFIRE-1811 at 7/8/20, 2:25 PM:
-
> we need separate module-info in src/test/module-info because we can add there
>additional dependencies, for example, junit, hamcrest etc.
[~Pavel_K] What prevents you from accessing those libraries while running on
the classpath? My understanding is that you should be able to just add them to
the dependencies section of pom.xml and you're good to go.
was (Author: cowwoc):
> we need separate module-info in src/test/module-info because we can add there
>additional dependencies, for example, junit, hamcrest etc.
[~Pavel_K] What prevents you from adding such dependencies into pom.xml without
adding a module file? You should be able to use said libraries from the
classpath.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153640#comment-17153640
]
Gili commented on SUREFIRE-1811:
> we need separate module-info in src/test/module-info because we can add there
>additional dependencies, for example, junit, hamcrest etc.
[~Pavel_K] What prevents you from adding such dependencies into pom.xml without
adding a module file? You should be able to use said libraries from the
classpath.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153638#comment-17153638
]
Gili commented on SUREFIRE-1811:
[~Pavel_K] Okay, I'm going to assume you're doing white-box testing in your
unit tests because otherwise you wouldn't need to access any private APIs. This
means you currently have two options:
# Omit {{src/main/module-info.java}}. Or
# Add {{src/test/module-info.java}} and add qualified exports from
{{src/main/module-info.java}} to your test module.
Either approach will allow your test module to access private APIs. What
prevents you from using either option?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153615#comment-17153615
]
Gili commented on SUREFIRE-1811:
> So, I think that 3.2 is the best solution and we need to support it in maven
> SF and FS
[~Pavel_K] I keep on asking and you keep on not answering: Why do you need this?
1. Either you are running integration tests which are by definition black-box
testing, in which case I don't understand why they need to access private APIs
not exported by {{src/main/module-info.java}}. Please explain.
2. Or, you are running whitebox unit tests, in which case I don't understand
why you insist on adding {{src/test/module-info.java}}. Please explain.
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[
https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147841#comment-17147841
]
Gili edited comment on MCOMPILER-423 at 6/29/20, 2:44 PM:
--
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
org.apache.maven.plugins
maven-jar-plugin
3.1.0
default-jar
jar
${project.build.outputDirectory}/${module.name}
{code}
was (Author: cowwoc):
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
{code}
> Unable to define qualified exports to unknown modules without triggering
> compiler warning
> -
>
> Key: MCOMPILER-423
> URL: https://issues.apache.org/jira/browse/MCOMPILER-423
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: qualified-exports-module-source-path.zip
>
>
> Following up on a discussion with [~khmarbaise] at
> [https://stackoverflow.com/q/53670052/14731]
> It doesn't seem to be possible to compile the attached testcase without
> triggering a compiler warning.
> Expected behavior: Maven compiler plugin should pass --module-source-path to
> avoid the compiler warning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[
https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147841#comment-17147841
]
Gili commented on MCOMPILER-423:
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
{code}
> Unable to define qualified exports to unknown modules without triggering
> compiler warning
> -
>
> Key: MCOMPILER-423
> URL: https://issues.apache.org/jira/browse/MCOMPILER-423
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: qualified-exports-module-source-path.zip
>
>
> Following up on a discussion with [~khmarbaise] at
> [https://stackoverflow.com/q/53670052/14731]
> It doesn't seem to be possible to compile the attached testcase without
> triggering a compiler warning.
> Expected behavior: Maven compiler plugin should pass --module-source-path to
> avoid the compiler warning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[ https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MCOMPILER-423: --- Affects Version/s: 3.8.1 > Unable to define qualified exports to unknown modules without triggering > compiler warning > - > > Key: MCOMPILER-423 > URL: https://issues.apache.org/jira/browse/MCOMPILER-423 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: qualified-exports-module-source-path.zip > > > Following up on a discussion with [~khmarbaise] at > [https://stackoverflow.com/q/53670052/14731] > It doesn't seem to be possible to compile the attached testcase without > triggering a compiler warning. > Expected behavior: Maven compiler plugin should pass --module-source-path to > avoid the compiler warning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[ https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MCOMPILER-423: --- Attachment: qualified-exports-module-source-path.zip > Unable to define qualified exports to unknown modules without triggering > compiler warning > - > > Key: MCOMPILER-423 > URL: https://issues.apache.org/jira/browse/MCOMPILER-423 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Gili >Priority: Major > Attachments: qualified-exports-module-source-path.zip > > > Following up on a discussion with [~khmarbaise] at > [https://stackoverflow.com/q/53670052/14731] > It doesn't seem to be possible to compile the attached testcase without > triggering a compiler warning. > Expected behavior: Maven compiler plugin should pass --module-source-path to > avoid the compiler warning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
