Do not resolve quarkus classpath if generate app model task is UP-TO-DATE #1
Conversation
| * and we don't want to do that if task is up-to-date | ||
| */ | ||
| @Classpath | ||
| public abstract ConfigurableFileCollection getOriginalClasspath(); |
There was a problem hiding this comment.
💭 This is the main change, we add getOriginalClasspath as an input that tracks original classpath instead of tracking Quarkus classpath as input
|
|
||
| private static String resolveClassifier(ModuleVersionIdentifier moduleVersionIdentifier, File file) { | ||
| String moduleGroupName = moduleVersionIdentifier.getVersion().isEmpty() | ||
| String artifactIdVersion = moduleVersionIdentifier.getVersion().isEmpty() |
There was a problem hiding this comment.
💭 Changes to this method are kinda unrelated, I just noticed there was a bug in resolving classifier
| } | ||
|
|
||
| private static Configuration[] getOriginalRuntimeClasspaths(Project project, LaunchMode mode) { | ||
| List<String> configurationNames = switch (mode) { |
There was a problem hiding this comment.
💭 These are original classpaths for every mode
| */ | ||
| @Internal | ||
| public abstract Property<ResolvedComponentResult> getRoot(); | ||
| public abstract Property<ArtifactCollection> getResolvedArtifactCollection(); |
There was a problem hiding this comment.
💭 I also changed QuarkusResolvedClasspath a bit so it uses ArtifactCollection now
17fcd30 to
68513c5
Compare
|
Hi @asodja, thank you very much! |
|
Results performance test with this approach(proposal 2): Incremental build (20 iterations) Project nessie Incremental build (20 iterations) Notes:
|
|
What are the changes for incremental done in the incremental build? I wonder why model gets invalidated. I think we could improve some things, e.g. Quarkus model depends just on the resources files, so for local project dependencies we could request just LibraryElements.RESOURCES and have that as an input. But maybe that is an idea that could be implemented by Quarkus developers or some contributor. :) |
This change should improve build time a bit when
quarkusGenerateAppModeltasks areUP-TO-DATEfor no configuration cache case.We try to avoid resolving quarkus classpaths by having only original classpaths as an input from which quarkus classpaths are calculated instead of quarkus classpaths themself.
In a build scan I still see that some quarkus configurations are resolved during configuration if
quarkusGenerateAppModelisUP-TO-DATE, but these are pretty fast:Compared to the version before where it was:
