Lóránt Pintér
committed
on 02 Sep 16
Keep track of file hierarchy for classpaths
Given a file structure like this:

/
/libs
library-a.jar
library-b.jar
/data
Keep track of file hierarchy for classpaths

Given a file structure like this:

/

/libs

library-a.jar

library-b.jar

/data

/a

input-1.txt

/b

input-2.txt

And a classpath like this:

C:\libs\library-a.jar;C:\libs\library-b.jar;C:\data

We need to normalize paths to this:

- "" (i.e. we ignore the path for library-a.jar)

- "" (same for library-b.jar)

- "a/input-1.txt" (notice that we ignore the root directory "data" itself!)

- "b/input-2.txt"

This allows us to ignore changes to the roots (i.e. it should make a difference for the JavaCompile task if `library-a.jar` was renamed to `other-library-a.jar` as long as contents stay the same). It also allows us to detect if `a/input-1.txt` is moved to `b/input-1.txt` (think of how that changes the behavior of `ClassLoader.getResource("a/input-1.txt")`.

Before this change we ignored every directory, and the whole path of every file on the classpath. This included ignoring the path of `a/input-1.txt`, so if that file was moved, we wouldn't detect the change. This is a false positive that we need to avoid at all cost.

This commit doesn't take us directly to the right solution, though. Instead, we'll keep track of the following information:

- "library-a.jar"

- "library-b.jar"

- "data"

- "data/a/input-1.txt"

- "data/b/input-2.txt"

Basically, we include the name of the root of the hierarchy, and don't remove root directories. This already allows us to detect `a/input-1.txt` being moved. The downside is that we produce false negatives (i.e. we needlessly consider the task out-of-date) when `library-a.jar` is renamed to `other-library-a.jar`. This will be addressed in a later change.

+review REVIEW-6170