Maven plugin install task doesn't work with v3.5

[asarkar]

The install task doesn't declare any output, causing up-to-date check to skip the task. Here's a snippet from running with --debug

18:09:43.673 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':install' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.

The workaround for this is to disable the up-to-date check.

tasks.install.outputs.upToDateWhen { false }

This works with 3.4 so 3.5 must have had some changes to up-to-date check or incremental build in general.

To make matters worse, 3.5 has a regression issue that it wrongly evaluates the local Maven directory.

Expected Behavior

1. install task should install the artifact in local Maven repo.
2. install task should print out the path to the installed artifact in INFO level.

Current Behavior

install task is skipped.

Steps to Reproduce (for bugs)

Extract the attached demo.zip and run ./gradlew clean install. Then go your to your local Maven repository and try to locate the jar file.

Your Environment

This is happening regardless of the OS, using Gradle 3.5.

[bmuschko]

You are correct that the install task doesn't define any outputs as indicated by the logs:

:install
Putting task artifact state for task ':install' into context took 0.0 secs.
Executing task ':install' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.

However, that only means that the install will always run and will never be up to date. As a result the existing artifacts are simply overwritten.

I do not see the install task being skipped for the sample project you provided so I cannot reproduce your issue. Please see my command line output after running it twice:

bmuschko@blizzard:~/Downloads/demo$ ./gradlew clean install
Parallel execution is an incubating feature.
:clean
:compileJava
:processResources
:classes
:jar
:install

BUILD SUCCESSFUL

Total time: 0.886 secs
bmuschko@blizzard:~/Downloads/demo$ ./gradlew clean install
Parallel execution is an incubating feature.
:clean
:compileJava
:processResources
:classes
:jar
:install

BUILD SUCCESSFUL

Total time: 0.822 secs

BTW: I'd advice providing a value for the group property so the Maven plugin ends up using the GAV you'd expect.

[asarkar]

@bmuschko The output you posted for up-to-date check shows that the task is skipped although it doesn't explicitly say so . Try putting tasks.install.outputs.upToDateWhen { false } and see it change to actually doing something.

The harder way of verifying this would be to run install, verify that the artifact got installed to local Maven repo, check the timestamp of the artifact, change the application.yml file, run install again, check the timestamp of the artifact. You'll see that the timestamp wouldn't change.

[asarkar]

From Gradle docs:

Introducing Incremental Build Support

Gradle checks that neither the inputs nor outputs have changed before executing a task.

I'm not sure why is this tagged as a question, where it is clearly a bug and should be tagged accordingly.

[bmuschko]

The output you posted for up-to-date check shows that the task is skipped.

I am not sure why you think Task has not declared any outputs. indicates that the task has been skipped. That is not the case.

Try putting tasks.install.outputs.upToDateWhen { false } and see it change to actually doing something.

This works for me with this code.

check the timestamp of the artifact

I can run install multiple times. The timestamp of the artifacts in the repository change and I can also see changes to files being reflected in the published JAR file e.g. in application.properties.

[asarkar]

And you're running Gradle 3.5, preferably using the wrapper?
Also, I think our problem was with a multimodule project. I'll try to create a reproducible project if you can't repro it on a multimodule project.

[bmuschko]

And you're running Gradle 3.5, preferably using the wrapper?

Yes, that is with the Wrapper you provided.

The modification date changes on the published artifacts. Also the lastUpdated attribute in maven-metadata-local.xml changes.

I'll try to create a reproducible project if you can't repro it on a multimodule project.

Please provide a sample project.

Do you maybe have any addition custom settings in settings.xml that could influence the behavior?

[asarkar]

@bmuschko

I am able to reproduce this issue using the project I'd already provided. Following are the steps:

1. ./gradlew build install
2. ls -l ~/.m2/repository/demo/0.0.1-SNAPSHOT/demo-0.0.1-SNAPSHOT.jar. Note the timestamp.
3. Wait a minute or 2.
4. Put a comment in src/main/java/com/example/demo/DemoApplication.java
5. Repeat steps 1 and 2.

You'll see that the jar in Maven repo is not updated. If you run a clean install, it will be. The problem is that the project artifact has changed in build/libs as the output of compileJava has changed, but the install task doesn't realize it.

I see no reason whatsoever that the install task will need to use the incremental build feature. It should hard-code the up-to-date check to false in the code. Or perhaps it can declare the artifact it is installing as the output so that if that changes, it always installs. Either way, it violates the incremental build principle that every task should define an output.

[bmuschko]

Sorry, I followed your steps but cannot reproduce the behavior you are describing. The JAR file is always recreated and the timestamp changes in the Maven repository. Also my install task is never up-to-date.

[bigdaz]

@asarkar the install task will never be skipped due to incremental build. That's what this message says:

18:09:43.673 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':install' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.

Note that it says Executing task ':install' due to:.

The fact that @bmuschko can't reproduce your failure using your supplied project and following your step-by-step instructions indicates that there's something else going on here.

A few things you can try:

• Remove ~/.m2/settings.xml before doing the install, and make sure it doesn't get created by Gradle. Otherwise, you might be affected by mavenLocal broken when <localRepository/> found in Maven settings.xml #1811 on the second install
• Try with the maven.repo.local system property set
• Provide a Build Scan demonstrating your failure: https://gradle.com/scans/get-started

[asarkar]

@bigdaz

Remove ~/.m2/settings.xml before doing the install

Don't have one.

Try with the maven.repo.local system property set

Why? If due to #1811, I don't have a custom settings.xml.

Provide a Build Scan

I can't reproduce this issue anymore so I'm going to close this issue. If I'm able to reproduce it later, I'll provide a build scan.

Thanks for looking into it.