Assume a JPMS build which depends on Scala 3.
dependencies {
…
implementation 'org.scala-lang:scala3-library_3:3.2.1'
}
Such a build needs to patch the org.scala.lang.scala3.library module, provided by scala3-library, because the module exports classes in the scala package and depends on scala-library, which also contains classes in the scala package. So right now I have to
modularity.patchModule("org.scala.lang.scala3.library", "scala-library-2.13.10.jar")
to avoid errors like "error: module scala.library reads package scala from both org.scala.lang.scala3.library and scala.library". However, it would be much user friendly, if the second parameter of patchModule(), could be provided as POM coordinate containing the group id and artifact id (":"), and not the version. For example
modularity.patchModule("org.scala.lang.scala3.library", "org.scala-lang:scala-library")
thus avoiding having to specify a concrete version, which may changes once I bump the version of scala3-library.
Assume a JPMS build which depends on Scala 3.
Such a build needs to patch the org.scala.lang.scala3.library module, provided by scala3-library, because the module exports classes in the
scalapackage and depends on scala-library, which also contains classes in thescalapackage. So right now I have toto avoid errors like "error: module scala.library reads package scala from both org.scala.lang.scala3.library and scala.library". However, it would be much user friendly, if the second parameter of
patchModule(), could be provided as POM coordinate containing the group id and artifact id (":"), and not the version. For examplethus avoiding having to specify a concrete version, which may changes once I bump the version of scala3-library.