Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task "jandex" up-to-date check passes as long as the jandex.idx exists (and will not rebuild for new source) #24

Closed
jskillin-idt opened this issue Nov 10, 2022 · 3 comments · Fixed by #27
Labels
released Issue has been released

Comments

@jskillin-idt
Copy link

jskillin-idt commented Nov 10, 2022

Description:
The "jandex" task will build the "jandex.idx" file once, and then appears to never build it again as long as it exists. At initial glance in the source, the "@InputFiles" field appears to be wired up to an empty file collection, which, if I understand Gradle correctly, implies that as long as the output exists, the task will pass the up-to-date check.

The "jandex" task ought to rebuild the "jandex.idx" when the class files that Jandex is indexing have changed.

Reproducer:
https://github.com/jskillin-idt/kordamp-jandex-gradle-plugin-issues-24

Steps to reproduce:

  1. Clone the repo and check out the "hi" branch.
  2. Run ./gradlew build and observe the "printMethods" task gives the list of methods present in src/main/java/com/sample/Test.java
  3. Without any further action, immediately check out the "hello" branch and run ./gradlew build again. Observe the "printMethods" task continues to give the old list of methods, despite src/main/java/com/sample/Test.java having been rewritten with new methods.
@jskillin-idt
Copy link
Author

(Reproducer added)

@jmini
Copy link
Contributor

jmini commented Aug 18, 2023

The reproducer is really helpful. 👍 .

When I run it:

./gradlew build --console=PLAIN first run:

Starting a Gradle Daemon (subsequent builds will be faster)

> Configure project :
Jandex Gradle plugin 1.0.0. Consider becoming a patron at https://www.patreon.com/aalmiray

> Task :compileJava
> Task :processResources NO-SOURCE
> Task :classes
> Task :compileTestJava NO-SOURCE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE
> Task :test NO-SOURCE
> Task :check UP-TO-DATE
> Task :jandex
> Task :jar
> Task :assemble

> Task :printMethods
void <init>()
void sayHi()

> Task :build

BUILD SUCCESSFUL in 14s
4 actionable tasks: 4 executed

git checkout hello and second run ./gradlew build --console=PLAIN:

> Configure project :
Jandex Gradle plugin 1.0.0. Consider becoming a patron at https://www.patreon.com/aalmiray

> Task :compileJava
> Task :processResources NO-SOURCE
> Task :classes
> Task :jandex UP-TO-DATE
> Task :jar
> Task :assemble
> Task :compileTestJava NO-SOURCE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE
> Task :test NO-SOURCE
> Task :check UP-TO-DATE

> Task :printMethods
void <init>()
void sayHi()

> Task :build

BUILD SUCCESSFUL in 729ms

The Task :jandex UP-TO-DATE is wrong in the second run.


I am not an expert, but I think that the problem is that when resolvedProcessDefaultFileSet is true (which is the default), the folder build/classes/java/main is not treated as being part of the input, because resolveSources() is called too late (configuration is already done and the folder is not part of the input):

if (resolvedProcessDefaultFileSet.get()) {
files.addAll((Collection<String>) sourceSets.findByName('main').output.classesDirs*.absolutePath.flatten())
}


My current work-around is to add the folder as additional input for the jandex task:

tasks.named('jandex') {
    inputs.files(sourceSets.findByName('main').output.classesDirs*.absolutePath.flatten())
        .withPropertyName('sourceFiles')
        .withPathSensitivity(PathSensitivity.RELATIVE)
}

jmini added a commit to jmini/kordamp-jandex-gradle-plugin-issues-24 that referenced this issue Aug 18, 2023
jmini added a commit to jmini/jandex-gradle-plugin that referenced this issue Aug 21, 2023
@aalmiray aalmiray added the released Issue has been released label Apr 30, 2024
@aalmiray
Copy link
Collaborator

🎉 This issue has been resolved in v2.0.0 (Release Notes)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released Issue has been released
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants