[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214828#comment-17214828
]
Robert Scholte commented on MCOMPILER-436:
------------------------------------------
sshd-core-2.5.1.jar contains
META-INF/services/java.nio.file.spi.FileSystemProvider, saying this jar
contains an implementation called
org.apache.sshd.common.file.root.RootedFileSystemProvider.
However, it is not sshd-core that contains this class, but sshd-common.
When compiling with the module path, this is verified as well, and it just
means that these jars are invalid and must be fixed by sshd. Worst solution is
to turn it into a Maven multimodule project, shade both sshd jars into a new
jar, and let you other module depend on that on.
But as said: let sshd fix this, they created invalid jars (that might work on
the classpath, but not on the modulepath anymore)
> 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)
