Is there a way for dependency resolution to take jar name into account instead of project name?

Help/Discuss
1

I have two projects. Project1 depends on Project2 like compile project(':project2'). Now in Project2 I change the base name of a jar file it produces like jar.baseName = 'xxx.jar'. At this point, Project1 stops being compilable as Gradle looks for build/libs/project2.jar in Project2’s output according to --debug but the file is called xxx.jar instead. Is there a way to tell Gradle that Project1’s dependency is called xxx.jar now? Thanks.

2

Gradle should not be looking for an exact file name unless this dependency has been hard-coded somewhere in your build. The project dependency should cause a dependency on a Configuration, which is a collection of files. The particular names don’t matter.

Creating a sample project with the information mentioned works as expected, so you might need to provide additional details to help determine what is causing the atypical behavior.

3

Here’s what I got down to so far. I have parent project and to child projects, core and reactor. The latter one depends on the former one. Parent project has no sources. I’m running clean build and here’s an output:

10:46:16 PM: Executing tasks 'clean build'...

:clean UP-TO-DATE
:core:clean
:reactor:clean
:assemble UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE
:core:compileJava
:core:processResources
:core:classes
:core:jar UP-TO-DATE
:core:assemble UP-TO-DATE
:core:compileTestJava
:core:processTestResources NO-SOURCE
:core:testClasses
:core:test
:core:check
:core:build
:reactor:compileJava FAILED

What caught my attention is that :core:jar reported UP-TO-DATE even though there was :core:clean and full build dir was purged so no jar file is available… Running build with clean build --rerun-tasks compiles everything fine as :core:jar executes and creates a jar file. I can’t reproduce this on a new project from scratch… I’m wondering though what might trigger jar task to report that it’s up to date after cleanup happened…

4

The case that comes to mind is setting the destinationDir to a folder other than the buildDir. In that case, the clean task would remove the build directory, but not the JAR placed outside of it. Even if that was the case, it doesn’t explain your original issue.

5

I suspect Gradle resorts to a project name when no file is found. At least that’s what I see at the moment. When xxx.jar file is there, classpath looks like build/libs/xxx.jar but when there is no one, it is build/libs/project2.jar.

Also, clean build --rerun-tasks creates xxx.jar exactly where it should be in build/libs/. This really puzzles me. Trying to figure out how jar’s up-to-date status is computed in the meantime.