https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
j
can you share the prints of 
./gradlew build --dry-run
?
e
if 
proto
is a 
java-library
, 
api
can consume its classes and resources without going through 
proto:assemble
a
Copy code
14:32:16: Executing 'clean build --dry-run'...

:clean SKIPPED
:api:clean SKIPPED
:proto:clean SKIPPED
:server:clean SKIPPED
:assemble SKIPPED
:spotlessCheck SKIPPED
:test SKIPPED
:proto:extractIncludeProto SKIPPED
:proto:extractProto SKIPPED
:proto:generateProto SKIPPED
:proto:compileJava SKIPPED
:proto:processResources SKIPPED
:api:extractIncludeProto SKIPPED
:api:extractProto SKIPPED
:api:generateProto SKIPPED
:api:compileJava SKIPPED
:api:processResources SKIPPED
:api:classes SKIPPED
:api:sourcesJar SKIPPED
:api:jar SKIPPED
:api:assemble SKIPPED
:api:findDuplicates SKIPPED
:spotlessInternalRegisterDependencies SKIPPED
:api:spotlessJava SKIPPED
:api:spotlessJavaCheck SKIPPED
:api:spotlessKotlin SKIPPED
:api:spotlessKotlinCheck SKIPPED
:api:spotlessCheck SKIPPED
:api:extractIncludeTestProto SKIPPED
:api:extractTestProto SKIPPED
:api:generateTestProto SKIPPED
:api:compileTestJava SKIPPED
:api:processTestResources SKIPPED
:api:testClasses SKIPPED
:proto:classes SKIPPED
:proto:sourcesJar SKIPPED
:proto:jar SKIPPED
:api:test SKIPPED
:api:verifyBreakingChanges SKIPPED
:api:verifyCyclicDependencies SKIPPED
:api:verifyDeniedModules SKIPPED
:api:verifyMajorVersion SKIPPED
:api:verifyDependencies SKIPPED
:api:check SKIPPED
:proto:assemble SKIPPED
:proto:findDuplicates SKIPPED
:proto:spotlessJava SKIPPED
:proto:spotlessJavaCheck SKIPPED
:proto:spotlessKotlin SKIPPED
:proto:spotlessKotlinCheck SKIPPED
:proto:spotlessCheck SKIPPED
:proto:extractIncludeTestProto SKIPPED
:proto:extractTestProto SKIPPED
:proto:generateTestProto SKIPPED
:proto:compileTestJava SKIPPED
:proto:processTestResources SKIPPED
:proto:testClasses SKIPPED
:proto:test SKIPPED
:proto:verifyBreakingChanges SKIPPED
:proto:verifyCyclicDependencies SKIPPED
:proto:verifyDeniedModules SKIPPED
:proto:verifyMajorVersion SKIPPED
:proto:verifyDependencies SKIPPED
:proto:check SKIPPED
:server:compileJava SKIPPED
:server:processResources SKIPPED
:server:classes SKIPPED
:server:sourcesJar SKIPPED
:server:jar SKIPPED
:server:assemble SKIPPED
:server:findDuplicates SKIPPED
:server:spotlessJava SKIPPED
:server:spotlessJavaCheck SKIPPED
:server:spotlessKotlin SKIPPED
:server:spotlessKotlinCheck SKIPPED
:server:spotlessCheck SKIPPED
:server:compileTestJava SKIPPED
:server:processTestResources SKIPPED
:server:testClasses SKIPPED
:server:test SKIPPED
:server:verifyBreakingChanges SKIPPED
:server:verifyCyclicDependencies SKIPPED
:server:verifyDeniedModules SKIPPED
:server:verifyMajorVersion SKIPPED
:server:verifyDependencies SKIPPED
:server:check SKIPPED
:gateOnAllTests SKIPPED
:api:jacocoTestReport SKIPPED
:proto:jacocoTestReport SKIPPED
:server:jacocoTestReport SKIPPED
:jacocoMerge SKIPPED
:jacocoTestReport SKIPPED
:check SKIPPED
:build SKIPPED
:api:build SKIPPED
:proto:build SKIPPED
:server:build SKIPPED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See <https://docs.gradle.org/7.4/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD SUCCESSFUL in 196ms
14:32:17: Execution finished 'clean build --dry-run'.
e
it can use the compiled classes and processed resources directly, rather than going through jar/assemble
a
I don't understand how that helps me in this case
My use case is that I have a task 
findDuplicates
which examines the contents of the jars files to check whether there are files with the same name in all the different jars
e
it explains why the ordering isn't there: 
:api:assemble
doesn't depend on 
:proto:assemble
, it depends on 
:proto:classes
etc.
a
What should I do to ensure that all the jars are available when 
findDuplicates
is run?
right now that is not the case because 
:api:findDuplicates
is run before 
:proto:assemble
e
why does it care whether there are jars or directories in the classpath?
and if it's depending directly on a jar output from other task, that's bad
a
The 
findDuplicates
task cares about the jar files because that is its source of information to examine whether there are duplicate file names
How should it be done if not like this?
e
just get api's runtime classpath
a
here is a code segment taken from the 
findDuplicates
task:
Copy code
@SuppressWarnings("LogAndThrow")
  private Set<ArtifactFile> readJarEntries(ResolvedArtifact artifact) {
    try (ZipFile zip = new ZipFile(artifact.getFile())) {
      return zip.stream()
          .filter(e -> !e.isDirectory())
          .filter(e -> !e.getName().startsWith("META-INF/"))
          .map(e -> new ArtifactFile(e.getName(), artifact, e.getCrc()))
          .collect(Collectors.toSet());
    } catch (IOException e) {
      if (!artifact.getFile().exists()) {
        throw new GradleException(
            "The jar "
                + artifact.getFile().toString()
                + " doesn't exist.\n Run `./gradlew build` to generate all of the project's jars.",
            e);
      }
      throw new GradleException("Error while opening jar '" + artifact.getFile() + "'", e);
    }
  }
artifact
represents a jar file
e
who is calling 
readJarEntries
, and with what values
a
Copy code
configuration.getResolvedConfiguration().getResolvedArtifacts().stream()
        .filter(a -> !a.getFile().toString().endsWith(".exe"))
        .filter(a -> !shouldIgnoreJar(a.getModuleVersion().toString()))
this is a code segment from earlier in the task that creates the collection of `ResolvedArtifract`s
e
that should work unless you're not properly depending on those files
a
it doesn't work
e
e.g.
Copy code
tasks.register("foo") {
    inputs.files(configurations.runtimeClasspath)
}
will cause gradle to build those jars, because you're asking for them
do not depend on side-effects of assemble
a
currently 
:api:findDuplicates
only depends on 
:api:assemble
e
then that's your problem, that isn't what actually provides the inputs you want
a
should I also add a dependency on 
:proto:assemble
then?
e
no
adding explicit task dependencies is usually the wrong answer, and always the wrong answer cross-project
a
oh i just re-read your message with the 
inputs.files
code segment. now I understand this is your recommendation how to rewrite the task properly
ok now i need to figure out how to do that in java
task.getInputs().files(project.getConfigurations().named("runtimeClasspath"));
I think this will work, trying it out now
j
Based on the dry run, 
api:assemble
is ran before 
proto:assemble
a
It works! Thank you @ephemient ❤️
e
Javi, calling 
assemble
(or 
build
) at the root doesn't force any particular order of the 
assemble
of subprojects, and there is no dependency between 
api:assemble
and 
proto:assemble
as I mentioned up at the start
👍 1
j
looks like a feature request for DRY RUN to show the task that are going to run but if the order is not guarantied, show them in parallel or whatever
e
there's stuff like https://github.com/dorongold/gradle-task-tree but I don't think there's really a good way to render it for large task graphs
thank you 1
6 Views
Open in Slack
PreviousNext
Powered by