-
Notifications
You must be signed in to change notification settings - Fork 984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automated java module checking #3411
Conversation
build.gradle
Outdated
@@ -286,6 +286,14 @@ subprojects { | |||
} | |||
} | |||
|
|||
task testModules(type: Exec) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is failing for me because:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for /.../micrometer/implementations/micrometer-registry-new-relic/build/libs/micrometer-registry-new-relic-1.10.0-SNAPSHOT.jar
Caused by: java.lang.module.FindException: Automatic-Module-Name: micrometer.registry.new.relic: Invalid module name: 'new' is not a Java identifier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this way, this is executed against the bom, the samples and the benchmarks too, I think this also fails since the bom does not have a jar.
I think it is an easy fix, we just need to put a few lines below, after this section:
jar {
manifest.attributes.put('Automatic-Module-Name', project.name.replace('-', '.'))
metaInf {
from "$rootDir/LICENSE"
from "$rootDir/NOTICE"
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a separate issue for the new relic automatic module name: #3412
build.gradle
Outdated
task testModules(type: Exec) { | ||
dependsOn "jar" | ||
|
||
commandLine "java", "-p", "${project.buildDir.absolutePath}${File.separator}libs${File.separator}/${project.name}-${project.version}.jar", "--list-modules" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This: libs${File.separator}/
will cause: libs//
but I would not bother building the path like this, since the jar task has a archivePath
property. Also, you can get the java executable path programmatically and we can add some error handling so that we see why the command failed:
task testModules(type: Exec) {
dependsOn jar
String executablePath = javaToolchains.launcherFor { languageVersion = javaLanguageVersion }.get().executablePath
commandLine "$executablePath", '-p', "$jar.archivePath", '--list-modules'
standardOutput = new ByteArrayOutputStream()
ignoreExitValue = true
doLast {
if (execResult.getExitValue() != 0) {
throw new GradleException("Command finished with non-zero exit value ${execResult.getExitValue()}:\n$standardOutput")
}
}
}
0699f87
to
abf665a
Compare
I've added a task called
testModules
that essentially callsIf the module system is broken this task will fail.
The motivation to add this check is to catch issues like the one found in #3398.
TODO:
testModules
to the whole build