I have a project with dozens of subprojects.
Only two of subprojects use a specific plugin.
That plugin fails during configuration (cannot find some defaults… like user directory ), but it is not the issue.
The issue is that I get the failure information during configuration of a subproject that is not applying the plugin at all.
Why?
Is org.gradle.parallel=true property involved?
org.gradle.parallel just means that tasks of different projects can be run in parallel, it should not influence the configuration phase.
What your problem stems from is hard to tell without seeing the actual project, or at least a build --scan URL.
Maybe you can knit an MCVE that demonstrates the problem?
1 Like
Hello Björn,
I do not want to blame the plugin neither the build script author in my team for the potential misconfiguration? of the plugin, it is not a showstopper or even build-break, I am just curious how these could be related:
02:14:07 > Configure project : … a subproject that DOES NOT use plugin id ‘com.gorylenko.gradle-git-properties’ version ‘2.4.2’
02:14:08 Problem determining the user home directory, trying Java user.home
02:14:08 java.nio.file.InvalidPathException: Illegal char <:> at index 3: .\h:
02:14:08 at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
02:14:08 at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
02:14:08 at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
02:14:08 at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
02:14:08 at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232)
02:14:08 at java.base/java.io.File.toPath(File.java:2387)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.FS.safeUserHomeImpl(FS.java:1198)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.FS.userHome(FS.java:1187)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.SystemReader$Default.getXDGConfigHome(SystemReader.java:114)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.SystemReader$Default.openJGitConfig(SystemReader.java:128)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.SystemReader.getJGitConfig(SystemReader.java:338)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.SystemReader.getSystemConfig(SystemReader.java:363)
02:14:08 at gradlegitproperties.org.eclipse.jgit.util.SystemReader.getUserConfig(SystemReader.java:311)
02:14:08 at gradlegitproperties.org.eclipse.jgit.internal.storage.file.FileRepository.(FileRepository.java:161)
02:14:08 at gradlegitproperties.org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:625)
02:14:08 at gradlegitproperties.org.eclipse.jgit.api.Git.open(Git.java:93)
02:14:08 at gradlegitproperties.org.eclipse.jgit.api.Git.open(Git.java:73)
02:14:08 at gradlegitproperties.org.eclipse.jgit.api.Git$open.call(Unknown Source)
02:14:08 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite.access$101(CallInterceptorsSet.java:150)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite$1.callOriginal(CallInterceptorsSet.java:164)
02:14:08 at org.gradle.internal.classpath.generated.InterceptorDeclaration_ConfigCacheGroovyInterceptors$OpenCallInterceptor.doIntercept(InterceptorDeclaration_ConfigCacheGroovyInterceptors.java:4020)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite.call(CallInterceptorsSet.java:161)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.operation.OpenOp.call(OpenOp.groovy:46)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.operation.OpenOp.call(OpenOp.groovy)
02:14:08 at java_util_concurrent_Callable$call.call(Unknown Source)
02:14:08 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.internal.OpSyntax.mapOperation(OpSyntax.groovy:20)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.internal.OpSyntax$mapOperation.callStatic(Unknown Source)
02:14:08 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:249)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.Grgit.open(Grgit.groovy)
02:14:08 at gradlegitproperties.org.ajoberstar.grgit.Grgit$open.call(Unknown Source)
02:14:08 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite.access$101(CallInterceptorsSet.java:150)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite$1.callOriginal(CallInterceptorsSet.java:164)
02:14:08 at org.gradle.internal.classpath.generated.InterceptorDeclaration_ConfigCacheGroovyInterceptors$OpenCallInterceptor.doIntercept(InterceptorDeclaration_ConfigCacheGroovyInterceptors.java:4020)
02:14:08 at org.gradle.internal.classpath.intercept.CallInterceptorsSet$DecoratingCallSite.call(CallInterceptorsSet.java:161)
02:14:08 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
02:14:08 at com.gorylenko.GitDirLocator.lookupGitDirectory(GitDirLocator.groovy:23)
02:14:08 at com.gorylenko.GitDirLocator$lookupGitDirectory.call(Unknown Source)
Really hard to tell just from that stripped stacktrace.
The method at the bottom of the shown trace part is only called when the tasks inputs are determined or queried (actually source and generatedProperties).
I can only guess that maybe the build somewhere tries to get one of those of the task in the other project (which is a relatively bad idea actually).
1 Like
Thanks Björn,
I have carefully reviewed the build script for the subproject and could not find any relation - traces of those (source or properties) - in it. No doubt there must be a misuse of the plugin (a kind of mixing the same the property keys in Gradle, Git and Spring annotation)… but even … I would expect the exception that manifest the misuse in a different subproject and not at the configuration phase.
Let me attach the full stack if that could be helpful … cannot attach it full as the message is limited to 4 while the stack is about 10KB
PS. the exception happened for 2 builds only, triggered by unrelated code changes.)
You can attach it as file I think.
But better would anyway be a build --scan URL if possible.
Or if neither, you can use any pastebin service like gist.github.com or pastebin.com.
But anyway the stacktrace might maybe not show the source of the problem and either the project or even better an MCVE could be necessary.
1 Like
Only picture attachments are allowed here, so get a haiku 02:14:07 > Configure project :f-xxxx:p-yyyy:w-zzzz02:14:08 Problem determining - Pastebin.com
Not Found (#404)
This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff.
Hi Björn,
here is a new stack record:
As I mentioned the issue had not a high priority in the project.
It occurred only in 2 automatic builds and were definitely not related to the changes (that triggered the build).
So it was and is a matter of curiosity now and probably of bad practices in build scripting with Gradle … something to learn.
B.R.
It looks to me like I assumed, that either you somewhere use the source property, or use the generatedProperties somewhere.
That it is at
02:14:08 at org.gradle.api.internal.file.CompositeFileCollection.visitDependencies(CompositeFileCollection.java:102)
[...]
02:14:08 at org.gradle.execution.plan.TaskDependencyResolver.resolveDependenciesFor(TaskDependencyResolver.java:49)
02:14:08 at org.gradle.execution.plan.LocalTaskNode.getDependencies(LocalTaskNode.java:148)
looks to me like you added that task or property to some file collection that is then queried for dependencies.
Maybe you can put a breakpoint at those stack frames and run the build through a debugger to see which tasks dependencies are resolved at that point.
1 Like