Why is gradle 2.x unpacking jar files?


At the moment we’re stuck with gradle 1.12 because it supports incremental compilation using Ant.

I tried to leverage the 2.1 incremental compilation feature in our build, but run into the different problem -> path length limits on Windows.

The problem is that jar files are unpacked to the build/temp folder and in java world the path tends to be really long. When you add:


files into the mix and you have to work on windows, you’re done. You’re forced to use gradle 1.x.

So my question is, why is gradle unpacking jar files in the first place? Is there any way to workaround this?

Thank you.

At the moment we’re stuck with gradle 1.12 because it supports incremental compilation using Ant.

Gradle 2.* does not remove the ant incremental compilation. Gradle 2.* adds a new incubating feature, the incremental compilation, however you are not obliged to use this new feature.

I’ve created a ticket for long paths on windows (it seems cleaner than converting this question to jira): GRADLE-3192

Hope that helps!

Thank you for your reply and filing an issue.

Regarding options.useAnt I though it was scheduled to be removed in 2.x with no replacement.

You are right, there is no replacement for this discontinued feature. I’ve missed that because we still have useDepend feature that requires useAnt :slight_smile: We need to remove options.useDepend, too. Anyhow, sorry that you cannot use Gradle 2.* at the moment. I hope you can consider using Gradle’s native compilation (no need to use ‘incremental’ for now) and still upgrade to Gradle 2.* Personally, I have not seen anyone using ant’s incremental java compilation ‘in real’ because of its limitations.

Well, our compilation takes ~15 minutes as opposed to ~5 minutes when incremental compilation can be used (usually the case when you change just few files).

I’ll keep an eye on the ticket.

Thank you.

The main reason I observed people are avoiding standard ant / javac incremental compilation is that eventually they end up with costly runtime error which root cause lies in the incorrect compilation. For example, changing a non-private static field will not be detected by javac’s dependency analysis resulting in a binaries that cannot be used reliably. I understand that optimization could be useful for local builds so just be cautious :slight_smile:

We’ll improve the incremental java compilation. Any chance you can try checking out the project closer to c:\ and trying out the incubating incremental compilation?