[
https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233514#comment-17233514
]
Guillaume Nodet commented on SSHD-1091:
---------------------------------------
[~lgoldstein] I know, we already had this discussion. Though I don't see the
benefit of the current split. Unit tests can be setup with a server/client
for the classes that require it and without for those that do not.
If we're going to a more modular build, I think we should split between common
/ client / server in addition to the current split between non-io / io related
classes.
That way, users would be able to use the client without requiring the server
and the opposite.
And if we're going for a 3.0 version, we should think on how to reduce the
footprint a bit as the sshd-osgi (which contains client + server) is almost
1.6M, which is _a lot._
> Java Module support
> -------------------
>
> Key: SSHD-1091
> URL: https://issues.apache.org/jira/browse/SSHD-1091
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 2.5.1
> Reporter: Gili
> Priority: Major
> Labels: important
>
> Please use the mechanism found at
> https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108
> to build multirelease JAR that will provide module-info.java for users of
> Java 9 and newer.
> The current JAR triggers many problems for users of Java Modules and in fact
> cannot be used at all in its current state due to
> https://issues.apache.org/jira/browse/MCOMPILER-436
> This might be a bug in the Maven Compiler plugin but I suspect that
> ultimately it will a problem with the library itself. For example, I noticed
> that Apache Mina (which this library depends on) has split packages. Split
> packages are incompatible with Java Modules.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
