-
Notifications
You must be signed in to change notification settings - Fork 77
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
Simplify logic surrounding building of Java & Kotlin parsers. #665
Conversation
Also simplify logic related to log statements, markers & return value
//Filter out any generated source files from the returned list, as we do not want to apply the recipe to the | ||
//generated files. | ||
Path buildDirectory = baseDir.relativize(Paths.get(mavenProject.getBuild().getDirectory())); | ||
Stream<SourceFile> sourceFiles = Stream.concat(parsedJava, parsedKotlin).filter(s -> !s.getSourcePath().startsWith(buildDirectory)); | ||
Stream<SourceFile> sourceFiles = Stream.concat(parsedJava, parsedKotlin) | ||
.filter(s -> !s.getSourcePath().startsWith(buildDirectory)) |
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.
Seems like it would be even better if we could filter out these generated sources before parsing them.
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 had thought we parse them such that we have their types available for attribution, as indicated on line 302 above. What improvement would you make here then?
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 suppose we have to test this, but these sources should still not need to be parsed, because the type attribution in other sources is via class files.
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 think it boils down to the question if getCompileClasspathElements()
returns the classes compiled fom generated sources as well, which could depend on a number of different factors.
rewrite-maven-plugin/src/main/java/org/openrewrite/maven/MavenMojoProjectParser.java
Lines 317 to 324 in 0b8fc33
logInfo(mavenProject, "Parsing source files"); | |
List<Path> dependencies = mavenProject.getCompileClasspathElements().stream() | |
.distinct() | |
.map(Paths::get) | |
.collect(toList()); | |
JavaTypeCache typeCache = new JavaTypeCache(); | |
javaParserBuilder.classpath(dependencies).typeCache(typeCache); | |
kotlinParserBuilder.classpath(dependencies).typeCache(new JavaTypeCache()); |
Right now we define generated sources as anything we find in the target/
directory, and parse those as source rather than compiled classes.
rewrite-maven-plugin/src/main/java/org/openrewrite/maven/MavenMojoProjectParser.java
Lines 302 to 308 in 0b8fc33
// Some annotation processors output generated sources to the /target directory. These are added for parsing but | |
// should be filtered out of the final SourceFile list. | |
List<Path> generatedSourcePaths = listJavaSources(mavenProject.getBasedir().toPath().resolve(mavenProject.getBuild().getDirectory())); | |
List<Path> mainJavaSources = Stream.concat( | |
generatedSourcePaths.stream(), | |
listJavaSources(mavenProject.getBasedir().toPath().resolve(mavenProject.getBuild().getSourceDirectory())).stream() | |
).collect(toList()); |
While I agree it might be interesting to not parse those generated sources as source files but rather only as classpath entries, I'm not entirely sure that would work in all cases, and verifying that would take more time than I currently have available. Are you ok merging this PR as-is to at least simplify the logic?
What's changed?
What's your motivation?
Readability suffered a bit when mentally trying to parse what we had before.
Then further improvements from there on as spotted.
Have you considered any alternatives or workarounds?
Could have merely gone for
javaParserBuilder.build()
in ternary, but that didn't yet help readability much.