Explicit JPMS support#163
Conversation
Motivation: The library supports JPMS providing an automatic module name. While this library aims to target Java 7, it remains possible using multi-release jar to support explicit JPMS modules. Changes: Update the build to use the module-info Maven jar which creates a module-info.class descriptor. Update jna dependency to use jna-jpms which also is a multi release jar with a module-info descriptor.
| exports: | ||
| - package: com.zaxxer.nuprocess | ||
| - package: com.zaxxer.nuprocess.codec | ||
| - package: com.zaxxer.nuprocess.internal |
There was a problem hiding this comment.
I think internal, linux, osx and windows should likely not be exported. They're all intended to be implementation details of using the API defined in com.zaxxer.nuprocess. For whatever use case(s) you're trying to support, is there a reason you're using those packages?
| <dependency> | ||
| <groupId>net.java.dev.jna</groupId> | ||
| <artifactId>jna</artifactId> | ||
| <artifactId>jna-jpms</artifactId> |
There was a problem hiding this comment.
I'm mildly concerned about this change. Other codebases that leverage NuProcess may have dependency managed jna, but may or may not have an entry for jna-jpms. They'd either need to exclude it, or switch their configuration over, to avoid getting both jna and jna-jpms (and potentially at different versions).
I'm not sure there's any good way around this, here in NuProcess's POM, but at a minimum this seems like something we should at least mention in CHANGES.md to try and raise visibility for consumers.
2 participants
Motivation:
The library supports JPMS providing an automatic module name.
While this library aims to target Java 7, it remains possible using multi-release jar to support explicit JPMS modules.
Changes:
Update the build to use the module-info Maven jar which creates a module-info.class descriptor.
Update jna dependency to use jna-jpms which also is a multi release jar with a module-info descriptor.