Replies: 2 comments 1 reply
-
Thanks for starting this discussion. We use AutoPlugin to implement most of sbt's default features like compiling and testing so I think we would need to expose those to the build users so they can configure them. One idea Olaf had a while back is to create an über JAR for sbt. If we then shade the transitive libraries then we would effectively hide non-sbt classes? |
Beta Was this translation helpful? Give feedback.
-
To properly solve this issue we need a way to declare that a compile dependency should be a runtime dependency for the consumer of your library (or sbt itself in this case). This feature is available in Gradle as API and implementation separation. It is not available in sbt but someone suggested to add it in sbt 2 here. Maybe this feature would not be too hard to implement: we could add a field in the module descriptor to declare that it should appear as a
Yeah that could work as well. But it is kind of hack and it is not replicable for other libraries.
I am not sure but maybe IntelliJ will try to index them as Java classes. They would not be really hidden for the IDE. |
Beta Was this translation helpful? Give feedback.
-
Hello!
In IntelliJ Scala Plugin we register special -build modules representing SBT project definition projects.
The classpath of that module includes 83 jar files reported by SBT (via sbt.PluginData#dependencyClasspath)
Those are needed to provide all the ordinary intelligence in IDEA (completion, navigation, etc...)
Right now all of them are accessible from IDEA and SBT (see the comment)
But we started wondering if all of those libraries are supposed to be visible to developers
It feels like many of those jars are implementation details and required only at runtime.
E.g. there are multiple default auto-plugins (sbt.ScriptedPlugin + 8 plugins from sbt.plugins._)
All of them look like an implementation detail, they are automatically applied by SBT, and in most of the cases you don't need to explicitly access them.
Still, they contribute a lot of transitive dependencies.
Those could be extracted to separate modules and hidden by default.
If users still want to use them, they could opt for them "somehow". It can be discussed, but it's doable.
SBT 2.0 looks like a good moment to rethink the internal module structure and define default API entities
Beta Was this translation helpful? Give feedback.
All reactions