[GRADLE-2868] Incremental compilation doesn't work for inputs of type java.util.regex.Pattern Created: 14/Aug/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Task
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

I am writing a custom task, and I am trying to use the incremental annotations by denoting the inputs and outputs. Here is an example:

class Notifier extends DefaultTask {
@Input Serializable matcher
@InputFile File file

@TaskAction void notifyIfMatching() {
if (matcher.isCase(file.text)) {
// send an email
}
}
}

task notify1(type: Notifier) {
file = file("foobar")
matcher = ~/.foo.*bar./
}

task notify2(type: Notifier) {
file = file("foobar")
matcher =

{ it ==~ ~/.*foo.*bar.*/ }

}

When I run twice: gradle notify1 notify2

I can see that notify1 is marked as UP TO DATE, while notify2 is evaluated every time. If I run with -d, I cans ee this is because of the "matcher" is presumed different.

 Comments   
Comment by Gradle Forums [ 14/Aug/13 ]

This is the expected behavior, as per the `equals` contract of `groovy.lang.Closure`. To get the desired behavior, you'll probably have to redesign the API (e.g. accept a `String` or `Pattern`).

Comment by Gradle Forums [ 14/Aug/13 ]

I am sorry, bad example - in practice I was using a Pattern literal, and I changed it to string later.

In the case of Pattern literal, Gradle thought that the value never matched the one from the build cache. What would be the way to debug this?

Unfortunately, I can not post the actual code.

Comment by Gradle Forums [ 14/Aug/13 ]

Turns out that `Pattern` doesn't implement `equals` either. Best use a String.

Comment by Gradle Forums [ 14/Aug/13 ]

That's what I am doing now, though in general I like being able to use GroovyObject.isCase() for specifying criteria.

May I suggest that Gradle adds special behavior for checking Input values in case of Pattern instances and instead of invoking the equals() on the instance itself, it compares against the return value of value.pattern() method?

This can be generalized to a registry of comparators per type, defaulting to equals() comparator.

Comment by Dimitar Dimitrov [ 14/Aug/13 ]

Defining the matcher as object is fairly common pattern in Groovy, i.e. the GroovyObject.grep(), the implementation of case patterns, etc.

This allows to write less code in the task implementation and retain the flexibility to specify the matcher as string literal, regex, or closure.

I can understand that closures can not be reasonably compared, but having it working for strings and regexes covers a lot of use cases.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:33:39 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.