You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Move equo caches into build / build tool directory #1687
The move to equo for the Eclipse-based formatters causes issues in out CI build. See #1524 (comment)
The problem is, that the plugin tries to write the equo cache into a directory that's not writable/resolvable.
I suggest moving the cache into the ${user.home}/.m2/GRADLE_USER_HOME directories or into the project build directory.
See also #1669 (comment)
Unfortunately, this doesn't seem to have the desired effect. Now I'm getting
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':spotlessCheck'.
> Could not create task ':spotlessGroovyGradleCheck'.
> Could not create task ':spotlessGroovyGradle'.
> java.io.IOException: Failed to load eclipse groovy formatter: java.lang.IllegalArgumentException: Need to create directory first! /gradle-home/daemon/8.1.1/?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/queries
Also, it is strange that System.getProperty("user.home") is returning /gradle-home/daemon/8.1.1/?/. Very strange... I tried to test for this exact case by creating the .m2 directory, seeing if there is an exception, and using that as a cue to read GRADLE_USER_HOME. I'm kinda surprised that we could create /gradle-home/daemon/8.1.1/?/.m2 ...
It's running in an eclipse-temurin:17-jdk Docker container.
Can you add --stacktrace?
Sure:
...
Caused by: java.io.IOException: Failed to load eclipse groovy formatter: java.lang.IllegalArgumentException: Need to create directory first! /gradle-home/daemon/8.1.1/?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/queries
at com.diffplug.spotless.extra.EquoBasedStepBuilder.get(EquoBasedStepBuilder.java:109)
at com.diffplug.spotless.FormatterStepImpl.calculateState(FormatterStepImpl.java:58)
at com.diffplug.spotless.LazyForwardingEquality.state(LazyForwardingEquality.java:56)
... 224 more
Caused by: java.lang.IllegalArgumentException: Need to create directory first! /gradle-home/daemon/8.1.1/?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/queries
at dev.equo.solstice.p2.FileMisc.writeToken(FileMisc.java:77)
at dev.equo.solstice.p2.QueryCacheOnDisk.<init>(QueryCacheOnDisk.java:34)
at dev.equo.solstice.p2.P2Model.query(P2Model.java:118)
at com.diffplug.spotless.extra.EquoBasedStepBuilder.get(EquoBasedStepBuilder.java:107)
... 226 more
Also, it is strange that System.getProperty("user.home") is returning /gradle-home/daemon/8.1.1/?/.
I tried to test for this exact case by creating the .m2 directory, seeing if there is an exception, and using that as a cue to read GRADLE_USER_HOME
Shouldn't we rather do it the other way around? I.e. check for GRADLE_USER_HOME first? The variable should serve as a clear indication that we're running in a Gradle context and even point us to the correct location. I'm not sure whether there's something similar for Maven though. ~/.m2 just seems to be the default.
Apparently, /gradle-home/daemon/8.1.1/?/ is what we get when trying to resolve it to an absolute directory
Yes, I think that's the problem. ? is resolved to an absolute directory depending on the working directory. And when initializing CacheLocations, it is the Gradle project's working directory. That one is writable, so we create $PROJECT_DIR/?/.m2/repository....
Later, when the EquoBasedStepBuilder runs, for some reason, the working directory is /gradle-home/daemon/8.1.1/, where the directory is obviously missing.
So, if new File(System.getProperty("user.home")) is not absolute, we should probably not use it.
I think that both suggestions above should fix that problem and I prefer the latter one.
to by build. That fixes the exception, however, now I get
...
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: ?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/nested-jars/org.codehaus.groovy_4.0.11.v202303311542-e2303.jar__eclipse-trace.jar__Z5ch70p+Jsgu4XHQc0MVqw--.jar (No such file or directory)
at dev.equo.solstice.Unchecked.wrap(Unchecked.java:47)
at dev.equo.solstice.NestedJars.extractNestedJar(NestedJars.java:323)
at dev.equo.solstice.NestedJars.extractAllNestedJars(NestedJars.java:291)
at dev.equo.solstice.NestedJars$OnClassPath.confirmAllNestedJarsArePresentOnClasspath(NestedJars.java:194)
at com.diffplug.spotless.extra.glue.groovy.GrEclipseFormatterStepImpl.<clinit>(GrEclipseFormatterStepImpl.java:55)
... 142 more
Caused by: java.io.FileNotFoundException: ?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/nested-jars/org.codehaus.groovy_4.0.11.v202303311542-e2303.jar__eclipse-trace.jar__Z5ch70p+Jsgu4XHQc0MVqw--.jar (No such file or directory)
at java.base/java.io.FileOutputStream.open0(Native Method)
at java.base/java.io.FileOutputStream.open(FileOutputStream.java:293)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:235)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:184)
at dev.equo.solstice.NestedJars.extractNestedJar(NestedJars.java:317)
... 145 more
Oh, I guess that's a forked process that has its own CacheLocations class and its own working directory. That makes a lot of sense.
I wonder if it inherits the GRADLE_USER_HOME env variable.
@nedtwigg, still not working. I added a version override to my build, but I get the same error as in #1687 (comment):
$ GRADLE_USER_HOME=/tmp ./gradlew --rerun-tasks -Duser.home=? spotlessGroovy
...
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: ?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/nested-jars/org.codehaus.groovy_4.0.11.v202303311542-e2303.jar__eclipse-trace.jar__Z5ch70p+Jsgu4XHQc0MVqw--.jar (Datei oder Verzeichnis nicht gefunden)
at dev.equo.solstice.Unchecked.wrap(Unchecked.java:47)
at dev.equo.solstice.NestedJars.extractNestedJar(NestedJars.java:323)
at dev.equo.solstice.NestedJars.extractAllNestedJars(NestedJars.java:291)
at dev.equo.solstice.NestedJars$OnClassPath.confirmAllNestedJarsArePresentOnClasspath(NestedJars.java:194)
at com.diffplug.spotless.extra.glue.groovy.GrEclipseFormatterStepImpl.<clinit>(GrEclipseFormatterStepImpl.java:55)
... 134 more
Caused by: java.io.FileNotFoundException: ?/.m2/repository/dev/equo/p2-data/repository/dev/equo/p2-data/nested-jars/org.codehaus.groovy_4.0.11.v202303311542-e2303.jar__eclipse-trace.jar__Z5ch70p+Jsgu4XHQc0MVqw--.jar (Datei oder Verzeichnis nicht gefunden)
at dev.equo.solstice.NestedJars.extractNestedJar(NestedJars.java:317)
... 137 more
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':spotlessGroovy'.
> java.lang.ExceptionInInitializerError (no error message)
Not sure what's happening. It looks as if NestedJars uses a different solstice version. So the override only works partially?
I still think it would be best if the Gradle plugin set the CacheLocations overrides since it knows where its user home is.
In mvn world, the local reposirory can be configured through -Dmaven.local.repo=XXX (https://stackoverflow.com/a/57223696/1439964). If this is customized, I feel EquoDev would write in the default local repository instead of the custom one.
I have the same problem. In a CI environment building in a docker container I would like to set the Maven repository directory to point inside the Jenkins workspace.
The problem is simple to reproduce. I have a simple groovy/greclipse spotless setup using version 2.41.1.
Make the ~/.m2 directory unwritable: chmod 000 ~/.m2/
;mvn spotless:apply
[ERROR] Could not create local repository at /home/maan0496/.m2/repository -> [Help 1]
I could work around the problem with (although it seems strange to a Maven user):
Activity
jochenberger commentedon Apr 26, 2023
The problem in my case is that
System.getProperty("user.home")returns"?"in https://github.com/equodev/equo-ide/blob/main/solstice/src/main/java/dev/equo/solstice/p2/CacheLocations.java#L111.nedtwigg commentedon May 24, 2023
Fixed in
plugin-gradle 6.19.0andplugin-maven 2.37.0.jochenberger commentedon May 24, 2023
Unfortunately, this doesn't seem to have the desired effect. Now I'm getting
jochenberger commentedon May 24, 2023
What if the Gradle/Maven plugin set
CacheLocations.override_p2dataappropriately instead of trying to figure out the current environment in solstice?nedtwigg commentedon May 24, 2023
Interesting! What system is this running on? I'm confused by the persistent
?thing.Can you add
--stacktrace? I believe the only place that this can be happening is downstream of here, where we clearly create the directory first.https://github.com/equodev/equo-ide/blob/35986ecdc5e6dd6dd5a293c348bfe0330e49ab96/solstice/src/main/java/dev/equo/solstice/p2/QueryCacheOnDisk.java#L29-L35
Also, it is strange that
System.getProperty("user.home")is returning/gradle-home/daemon/8.1.1/?/. Very strange... I tried to test for this exact case by creating the.m2directory, seeing if there is an exception, and using that as a cue to readGRADLE_USER_HOME. I'm kinda surprised that we could create/gradle-home/daemon/8.1.1/?/.m2...https://github.com/equodev/equo-ide/blob/35986ecdc5e6dd6dd5a293c348bfe0330e49ab96/solstice/src/main/java/dev/equo/solstice/p2/CacheLocations.java#L80-L92
jochenberger commentedon May 24, 2023
It's running in an
eclipse-temurin:17-jdkDocker container.Sure:
It isn't. It's returning
?(probably because PAM is not available, see https://stackoverflow.com/questions/1503284/java-system-getpropertyuser-home-returns).Apparently,
/gradle-home/daemon/8.1.1/?/is what we get when trying to resolve it to an absolute directory, which we do to create the error message (https://github.com/equodev/equo-ide/blob/solstice/1.3.1/solstice/src/main/java/dev/equo/ide/FileMisc.java#L77). I think we're shadowing the real issue here.jochenberger commentedon May 24, 2023
Shouldn't we rather do it the other way around? I.e. check for
GRADLE_USER_HOMEfirst? The variable should serve as a clear indication that we're running in a Gradle context and even point us to the correct location. I'm not sure whether there's something similar for Maven though.~/.m2just seems to be the default.jochenberger commentedon May 24, 2023
Maybe
GRADLE_USER_HOMEisn't passed down to Solstice at all? 🤔I think we should try to set
CacheLocations.override_p2datafrom the plugin code.jochenberger commentedon May 24, 2023
Yes, I think that's the problem.
?is resolved to an absolute directory depending on the working directory. And when initializingCacheLocations, it is the Gradle project's working directory. That one is writable, so we create$PROJECT_DIR/?/.m2/repository....Later, when the
EquoBasedStepBuilderruns, for some reason, the working directory is/gradle-home/daemon/8.1.1/, where the directory is obviously missing.So, if
new File(System.getProperty("user.home"))is not absolute, we should probably not use it.I think that both suggestions above should fix that problem and I prefer the latter one.
jochenberger commentedon May 24, 2023
I tried adding
to by build. That fixes the exception, however, now I get
jochenberger commentedon May 24, 2023
Oh, I guess that's a forked process that has its own
CacheLocationsclass and its own working directory. That makes a lot of sense.I wonder if it inherits the
GRADLE_USER_HOMEenv variable.nedtwigg commentedon May 25, 2023
I just took another hack at it
published in
solstice 1.3.2. It'll be at least a few weeks before a new Spotless comes that uses these.jochenberger commentedon May 25, 2023
Looks promising, thanks!
jochenberger commentedon May 25, 2023
@nedtwigg, still not working. I added a version override to my build, but I get the same error as in #1687 (comment):
Not sure what's happening. It looks as if
NestedJarsuses a different solstice version. So the override only works partially?I still think it would be best if the Gradle plugin set the CacheLocations overrides since it knows where its user home is.
blacelle commentedon Jun 24, 2023
In mvn world, the local reposirory can be configured through
-Dmaven.local.repo=XXX(https://stackoverflow.com/a/57223696/1439964). If this is customized, I feel EquoDev would write in the default local repository instead of the custom one.I also have related issues by deploying Spotless to AWS Lambda, as
user.homeresolves to something inexistent+read-only (https://stackoverflow.com/questions/61614561/aws-lambda-java-runtime-home-directory-does-not-exist).attiand commentedon Dec 19, 2023
I have the same problem. In a CI environment building in a docker container I would like to set the Maven repository directory to point inside the Jenkins workspace.
The problem is simple to reproduce. I have a simple groovy/greclipse spotless setup using version 2.41.1.
Make the ~/.m2 directory unwritable:
chmod 000 ~/.m2/I could work around the problem with (although it seems strange to a Maven user):
I would like spotless to honor the
maven.repo.localproperty, so I could write:jochenberger commentedon May 29, 2026
Fixed in https://github.com/diffplug/spotless/releases/tag/maven%2F3.6.0 / https://github.com/diffplug/spotless/releases/tag/gradle%2F8.6.0 🥳