You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using jnr-fuse in projects using the JPMS, the module name is derived from the jar file, which doesn't exactly lead to reliable builds.
Even without migrating to JPMS, libraries can easily become somewhat JPMS-compatible (at least if not sharing packages with other modules, see #102) by adding an automatic module name to the jar file:
With Gradle, you can configure the jar plugin as follows:
Due to package-private access to classes in upstream dependency? Maybe, if it is a good idea to extend those classes, the jffi-people should then widen the scope? Or maybe this utility can be added upstream?
Anyway it seems like this blocks any short-term solution.
When using jnr-fuse in projects using the JPMS, the module name is derived from the jar file, which doesn't exactly lead to reliable builds.
Even without migrating to JPMS, libraries can easily become somewhat JPMS-compatible (at least if not sharing packages with other modules, see #102) by adding an automatic module name to the jar file:
Source: http://branchandbound.net/blog/java/2017/12/automatic-module-name/
The text was updated successfully, but these errors were encountered: