Motivation:
The internalDependencyClasspath task in sbt relies on the trackInternalDependencies setting, which is set to TrackAlways by default. This means that invoking this task can potentially trigger a compilation.
Because of this, in IntelliJ IDEA, we avoid using the internalDependencyClasspath task directly for acquiring inter-project dependencies. Instead, we use sbt.internal.ClasspathImpl.interSort utility method, which allows us to avoid triggering compilation with exportedProducts. Besides, for IntelliJ IDEA, we don’t really need the classpath for inter-project dependencies; we only need the information about which project depends on which and in what configurations.
In general this approach works well. However, since our support doesn’t rely directly on any sbt key, users lose the ability to customize the order of the project dependencies classpath in any specific way.
Proposal:
Implement a new task that essentially performs the same function as internalDependencyClasspath, but without relying on trackInternalDependencies and without triggering compilation. This task could be named something like internalDependencyClasspathNoTracking.
^^
There shouldn't be a lot of implementation, and I'm willing to take this on. I just wanted to start a conversation to discuss whether it's fine to implement something like this, or if you might see a better workaround for the issue presented.
Motivation:
The
internalDependencyClasspathtask in sbt relies on thetrackInternalDependenciessetting, which is set toTrackAlwaysby default. This means that invoking this task can potentially trigger a compilation.Because of this, in IntelliJ IDEA, we avoid using the
internalDependencyClasspathtask directly for acquiring inter-project dependencies. Instead, we usesbt.internal.ClasspathImpl.interSortutility method, which allows us to avoid triggering compilation withexportedProducts. Besides, for IntelliJ IDEA, we don’t really need the classpath for inter-project dependencies; we only need the information about which project depends on which and in what configurations.In general this approach works well. However, since our support doesn’t rely directly on any sbt key, users lose the ability to customize the order of the project dependencies classpath in any specific way.
Proposal:
Implement a new task that essentially performs the same function as
internalDependencyClasspath, but without relying ontrackInternalDependenciesand without triggering compilation. This task could be named something likeinternalDependencyClasspathNoTracking.^^
There shouldn't be a lot of implementation, and I'm willing to take this on. I just wanted to start a conversation to discuss whether it's fine to implement something like this, or if you might see a better workaround for the issue presented.