GroovyJarFile cannot resolve a symlink location in the classpath about gradle HOT 7 CLOSED

Absolutely @big-guy I can do that. In fact I already prototyped it to prove it works and patch internally as an experiment. So, it would be easy to make it happen.

I can also add the suggested optimization to only resolve the file path if there is a potential pattern match with groovy in the file name as this is definitively the use case we have, we retain the groovy part just all others are mutated in the symlink. The target of course is the source of truth.

from gradle.

There is a potential performance problem of requesting a real path, because the method is invoked for every library in the classpath. Probably it can be resolved with two levels of checks, limiting the real path resolution to only something that has groovy in its filename. Would it work in your use case?

from gradle.

Good point and yes, that would work. Our naming conventions happen to keep the groovy name but other aspects including version numbers and group are twisted. The ideal option is to have the resolved symlink for the names that are likely to be candidates.

from gradle.

The issue is in the backlog of the relevant team and is prioritized by them.

from gradle.

@Alex-Vol-Amz would you be interested in submitting your change as a PR?

The real fix for this would be to remove the need for GroovyJarFile entirely, but this is a deeper change to the way the Groovy plugin works.

from gradle.

@Alex-Vol-Amz we can see if the performance impact as you have it is a big deal with our tests. You can just submit what you have plus an integ test.

from gradle.

I posted the working PR with unit tests. I have not come up with a clever way to simulate this environment in an integration test yet. If you think an integration test is a must have I will try to work out the detail. I may end up using the mechanism I did for the example project that reproduced the issue on the description of this bug.

from gradle.