Upgrading 0.12.5 -> 0.12.6 or 0.12.7 breaks the build with StackOverflowError
#4457
Comments
|
Error: |
|
Thanks for the report @arturaz ! @alexarchambault could you take a look at this? Seems like there's some unexpected circularity that may be caused by #4145 |
lefou
changed the title
1.12.5 -> 1.12.6 or 1.12.7 breaks the build with StackOverflowError0.12.5 -> 0.12.6 or 0.12.7 breaks the build with StackOverflowError
|
Having a look… |
|
@arturaz Do you a clean repro for this? I'm having a hard time reproducing this from your repo and the |
|
It seems it is related to scalably typed plugin. This reproduces for me: mill-repro.tar.gz |
alexarchambault
added a commit
to alexarchambault/mill
that referenced
this issue
Feb 3, 2025
mill-scalablytyped (but possibly other plugins or user setups too) adds a dependency on `repositoriesTask` from `ivyDeps`. Since the introduction of `JavaModule#coursierProject`, Mill had a dependency the other way around, `repositoriesTask` depends on `ivyDeps`. This creates a cycle, leading to StackOverflowException-s. In order to work around that, this PR splits both `repositoriesTask` and `defaultResolver`, adding: - `allRepositoriesTask`: basically `repositoriesTask`, with the Mill internal repository added - `internalResolver`: same as `defaultResolver`, with the Mill internal repository added (via `allRepositoriesTask`) If users need to resolve purely external modules (most common case it seems), they can keep using `repositoriesTask` or `defaultResolver`. If they need to resolve some Mill internal modules (usually brought in via `JavaModule#coursierDependency`), they now need to use `allRepositoriesTask` and `internalResolver` instead of `repositoriesTask` and `defaultResolver`. That way, no cycle is introduced when users only need to resolve external modules. Fixes com-lihaoyi#4457
alexarchambault
added a commit
to alexarchambault/mill
that referenced
this issue
Feb 3, 2025
mill-scalablytyped (but possibly other plugins or user setups too) adds a dependency on `repositoriesTask` from `ivyDeps`. Since the introduction of `JavaModule#coursierProject`, Mill had a dependency the other way around, `repositoriesTask` depends on `ivyDeps`. This creates a cycle, leading to StackOverflowException-s. In order to work around that, this PR splits both `repositoriesTask` and `defaultResolver`, adding: - `allRepositoriesTask`: basically `repositoriesTask`, with the Mill internal repository added - `internalResolver`: same as `defaultResolver`, with the Mill internal repository added (via `allRepositoriesTask`) If users need to resolve purely external modules (most common case it seems), they can keep using `repositoriesTask` or `defaultResolver`. If they need to resolve some Mill internal modules (usually brought in via `JavaModule#coursierDependency`), they now need to use `allRepositoriesTask` and `internalResolver` instead of `repositoriesTask` and `defaultResolver`. That way, no cycle is introduced when users only need to resolve external modules. Fixes com-lihaoyi#4457
alexarchambault
added a commit
to alexarchambault/mill
that referenced
this issue
Feb 3, 2025
mill-scalablytyped (but possibly other plugins or user setups too) adds a dependency on `repositoriesTask` from `ivyDeps`. Since the introduction of `JavaModule#coursierProject`, Mill had a dependency the other way around, `repositoriesTask` depends on `ivyDeps`. This creates a cycle, leading to StackOverflowException-s. In order to work around that, this PR splits both `repositoriesTask` and `defaultResolver`, adding: - `allRepositoriesTask`: basically `repositoriesTask`, with the Mill internal repository added - `internalResolver`: same as `defaultResolver`, with the Mill internal repository added (via `allRepositoriesTask`) If users need to resolve purely external modules (most common case it seems), they can keep using `repositoriesTask` or `defaultResolver`. If they need to resolve some Mill internal modules (usually brought in via `JavaModule#coursierDependency`), they now need to use `allRepositoriesTask` and `internalResolver` instead of `repositoriesTask` and `defaultResolver`. That way, no cycle is introduced when users only need to resolve external modules. Fixes com-lihaoyi#4457
alexarchambault
added a commit
to alexarchambault/mill
that referenced
this issue
Feb 4, 2025
mill-scalablytyped (but possibly other plugins or user setups too) adds a dependency on `repositoriesTask` from `ivyDeps`. Since the introduction of `JavaModule#coursierProject`, Mill had a dependency the other way around, `repositoriesTask` depends on `ivyDeps`. This creates a cycle, leading to StackOverflowException-s. In order to work around that, this PR splits both `repositoriesTask` and `defaultResolver`, adding: - `allRepositoriesTask`: basically `repositoriesTask`, with the Mill internal repository added - `internalResolver`: same as `defaultResolver`, with the Mill internal repository added (via `allRepositoriesTask`) If users need to resolve purely external modules (most common case it seems), they can keep using `repositoriesTask` or `defaultResolver`. If they need to resolve some Mill internal modules (usually brought in via `JavaModule#coursierDependency`), they now need to use `allRepositoriesTask` and `internalResolver` instead of `repositoriesTask` and `defaultResolver`. That way, no cycle is introduced when users only need to resolve external modules. Fixes com-lihaoyi#4457
This was referenced Feb 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
0.12.7-7-83a00cis also affected.Building with https://github.com/arturaz/scala-web-framework-build succeeds, thus it seems the error is in this build file:
build.mill:The text was updated successfully, but these errors were encountered: