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 the plugin on a project with a module-info.java file we get following WARNING:
[WARNING] Failed to load class module-info from xxxxxx.jar due to: java.lang.NoClassDefFoundError module-info is not a class because access_flag ACC_MODULE is set
For a java module, the API is defined by the module-info file:
the exported packages are part of the API
the non-exported packages are NOT part of the API
the changes in the non-exported packages should be treated as a patch
changes to the list of required modules should be treated like changes to the list of dependencies
I think it would make sense to have a new configuration parameter allowing to check the SemVer semantics on JPMS level or not: even if the project uses JPMS we may want to ensure SemVer for usage without module by non modular applications. But by default it makes sense to work at module level for a project with a module-info file.
The text was updated successfully, but these errors were encountered:
When using the plugin on a project with a module-info.java file we get following WARNING:
[WARNING] Failed to load class module-info from xxxxxx.jar due to: java.lang.NoClassDefFoundError module-info is not a class because access_flag ACC_MODULE is set
For a java module, the API is defined by the module-info file:
I think it would make sense to have a new configuration parameter allowing to check the SemVer semantics on JPMS level or not: even if the project uses JPMS we may want to ensure SemVer for usage without module by non modular applications. But by default it makes sense to work at module level for a project with a module-info file.
The text was updated successfully, but these errors were encountered: