Skip to content
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

Run forbidden api checks with runtimeJavaVersion #32947

Merged
merged 8 commits into from
Aug 22, 2018

Conversation

alpar-t
Copy link
Contributor

@alpar-t alpar-t commented Aug 17, 2018

Switching to the CLI version of the tool allows us to run it with the runtime java version.
The newly introduced task just a thin wrapper over the cli args and we configure it as before from precommit. Since we only used it in one place, the extensions is no longer used as tasks.withType achieves the same goal.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

spec.classpath(sourceSet.runtimeClasspath)
spec.executable = "${project.runtimeJavaHome}/bin/java"
}
targetCompatibility = JavaVersion.VERSION_1_8 // FIXME: change to min(compilerVersion, 10)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will wait for the PR fixing the violations to be merged before changing this and merging this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should always be compiler version? That way if eg we use java 11, we will detect problems ahead of time, before we switch to using java 11 all the time?

private Set<String> suppressAnnotations = new LinkedHashSet<>();
private JavaVersion targetCompatibility;
private FileCollection classesDirs;
private Action<JavaExecSpec> execAction;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This avoids inheriting from JavaExec. I prefer that because this way the task can control when to do the exec and we can do the required setup in the task action.
Gradle runs the task action of the inherited task first ( I couldn't find a documented order ).

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @atorok. I have a few comments.

spec.classpath(sourceSet.runtimeClasspath)
spec.executable = "${project.runtimeJavaHome}/bin/java"
}
targetCompatibility = JavaVersion.VERSION_1_8 // FIXME: change to min(compilerVersion, 10)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should always be compiler version? That way if eg we use java 11, we will detect problems ahead of time, before we switch to using java 11 all the time?

getProject().javaexec((JavaExecSpec spec) -> {
execAction.execute(spec);
// This works because forbidden apis has no transitive dependencies.
spec.classpath(ClassPathUtils.getJar(CliMain.class));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I know we still need forbidden on the gradle classpath because we invoke it through ant for third-party-audit, I think once we move that to use cli, we should change this to have forbidden api in a separate configuration and pull it there, instead of this hack on finding where a class we have already loaded is located.


public class ClassPathUtils {

public static Path getJar(Class<?> theClass) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this hack, and especially not making it easier to use. Can it be isolated, or at least given large warning comments to not use this?

throw new AssertionError(e);
}
if (Files.exists(path) == false) {
throw new AssertionError("Bath to class source does not exist: " + path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: bath -> path

}
existingOutputs.forEach { args "-d", it }
classesDirs = sourceSet.output.classesDirs
ext.replaceSignatureFiles = { String... names ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we stick with the dsl of forbidden apis, instead of adding these helpers? I would like us to be able to switch back if/when it supports forking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It this is the only concern, we can add these helpers with any implementation of the task.
I don't have a strong preference, but do like how these make the build scripts shorter, without involving build resources.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, that is fine. Can we please name it set instead of replace then, to match common naming with other gradle dsl elements?

Copy link
Contributor Author

@alpar-t alpar-t Aug 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rjernst set will not work, as the task already has that method, so the extension will never be fetched and called, but even with something like setSignatures it would be confusing as I don't think signatures = ... would work, as it won't call the closure on task extensions but look for a set method on the task instance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to merge and submit a PR for the third party audit as well.
Let me know and I'll make changes to the name if needed,

// This works because the class only depends on one class from junit that will be available from the
// tests compile classpath. It's the most straight forward way of telling Java where to find the main
// class.
ClassPathUtils.getJar(NamingConventionsCheck.class).toFile(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if we kept this url hack as it was and didn't make it easier to use

@alpar-t
Copy link
Contributor Author

alpar-t commented Aug 20, 2018

@rjernst I reverted the hack, and wired it to compiler version.

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. A couple last nits.

)
spec.executable = "${project.runtimeJavaHome}/bin/java"
}
inputs.files(
sourceSet.compileClasspath,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the forbidden apis configuration also be an input?

}

@TaskAction
public void writeMarker() throws IOException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this method name does not seem accurate, since it does the actual execution, not just writing the marker file

}
existingOutputs.forEach { args "-d", it }
classesDirs = sourceSet.output.classesDirs
ext.replaceSignatureFiles = { String... names ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, that is fine. Can we please name it set instead of replace then, to match common naming with other gradle dsl elements?

@alpar-t alpar-t merged commit 82d10b4 into elastic:master Aug 22, 2018
@alpar-t alpar-t deleted the forbidden-APIs-checks-jvm-31715-part2 branch August 22, 2018 06:05
alpar-t added a commit to alpar-t/elasticsearch that referenced this pull request Aug 27, 2018
Run forbidden APIs checks with runtime hava version
jasontedor added a commit that referenced this pull request Aug 27, 2018
* 6.x:
  Introduce mapping version to index metadata (#33147)
  Move non duplicated actions back into xpack core (#32952)
  HLRC: Create server agnostic request and response (#32912)
  Build: forked compiler max memory matches jvmArgs (#33138)
  * Added breaking change section for GROUP BY behavior: now it considers null or empty values as a separate group/bucket. Previously, they were ignored. * This is part of backporting of #32832
  SQL: Enable aggregations to create a separate bucket for missing values (#32832)
  [TEST] version guard for reload rest-api-spec
  Fix grammar in contributing docs
  APM server monitoring (#32515)
  Support only string `format` in date, root object & date range (#28117)
  [Rollup] Move toBuilders() methods out of rollup config objects (#32585)
  Accept Gradle build scan agreement (#30645)
  Fix forbiddenapis on java 11  (#33116)
  Run forbidden api checks with runtimeJavaVersion (#32947)
  Apply publishing to genreate pom (#33094)
  Fix a mappings update test (#33146)
  Reload Secure Settings REST specs & docs (#32990)
  Refactor CachingUsernamePassword realm (#32646)
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >non-issue Team:Delivery Meta label for Delivery team v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants