How do I debug an always executing Jar task (in the context of incremental build)?

Old Forum Archive
1

In one of my modules I have a Jar task which always runs, regardless that the classes did not change. When I run the build with -i, it tells me that the Jar task is ran because “No history is available.” - here is a sample extract from the build log (formatted for readability):

INF - AbstractTaskPlanExecutor
      - :stream:classes (Thread[Task worker 1,5,main] - start
LIF - TaskExecutionLogger
           - :stream:classes
DEB - ExecuteAtMostOnceTaskExecuter
 - Starting to execute task ':stream:classes'
INF - SkipTaskWithNoActionsExecuter
 - Skipping task ':stream:classes' as it has no actions.
DEB - ExecuteAtMostOnceTaskExecuter
 - Finished executing task ':stream:classes'
LIF - TaskExecutionLogger
           - :stream:classes UP-TO-DATE
INF - AbstractTaskPlanExecutor
      - :stream:classes (Thread[Task worker 1,5,main]) - complete
  INF - AbstractTaskPlanExecutor
      - :stream:jar (Thread[Task worker 1,5,main] - start
LIF - TaskExecutionLogger
           - :stream:jar
DEB - ExecuteAtMostOnceTaskExecuter
 - Starting to execute task ':stream:jar'
DEB - SkipUpToDateTaskExecuter
      - Determining if task ':stream:jar' is up-to-date
INF - SkipUpToDateTaskExecuter
      - Executing task ':stream:jar' due to: No history is available.
DEB - ExecuteActionsTaskExecuter
    - Executing actions for task ':stream:jar'.
DEB - ExecuteAtMostOnceTaskExecuter
 - Finished executing task ':stream:jar'
INF - AbstractTaskPlanExecutor
      - :stream:jar (Thread[Task worker 1,5,main]) - complete
DEB - AbstractTaskPlanExecutor
      - Task worker [Thread[Task worker 1,5,main]] finished, busy: ...
DEB - DefaultTaskGraphExecuter
      - Timing: Executing the DAG took 0.389 secs

As you can see, the classes task didn’t even run, so the class files have not changed, but regardless how many times in a raw I run the build, the Jar task always runs. This causes ripple effect and my build ends up recompiling a number of other projects.

2

Answering my own question I found out that we used timestamp as the version for dev builds, which caused the build to produce new jar every time.

3

Using ‘-i’ is the best way to diagnose these issues. It’s very strange that you were always getting the message about no history being available. I’d expect that to happen on the first run, but that’s it.

Can you confirm you received this message every time?

4

I did receive the message every time - when I fixed the version name not to include the timestamp I managed to get proper incremental behavior. FWIW, we have manifest for every jar and it includes the project version as one of its entries (but that was not the message I got).

5

That’s a bug then.

Any chance you could construct a cut down sample that exhibits the same issue that we could use to drive the fix?