Giters

lightbend-labs / dbuild

Multi-project build tool, based on sbt.

Home Page:https://lightbend-labs.github.io/dbuild

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

support Scala.js

SethTisue opened this issue · comments

commented

I don't know what the chances of this happening are, but let's have a ticket for it, at least.

currently in the Scala community build we have to disable Scala.js subprojects since it's pretty much guaranteed that dbuild will complain that the JVM subproject and the corresponding Scala.js subproject publish the same artifact.

over at #188, @dwijnand suggested that (in order to fix a different issue) dbuild ought to determine uniqueness using the artifactId:

This would allow, as an example, dbuild to not fail when seeing both a cats-core for JVM and a cats-core for JS, by seeing them as org.typelevel#cats-core_2.11 and org.typelevel#cats-core_sjs0.6_2.11 instead

/cc @sjrd

commented

@cunei when you fixed #188, did you take the path @dwijnand suggested, or a different one?

commented

Edit: Oops sorry I didn't read the initial description well enough. My comment below appears to repeat @dwijnand's suggestion.

dbuild will complain that the JVM subproject and the corresponding Scala.js subproject publish the same artifact

They do not, though. For a cross-compiled foo project, the JVM subproject publishes foo_2.11 whereas the JS subproject publishes foo_sjs0.6_2.11. If dbuild complains that those are the same, I guess the first thing to look at would to fix that.

commented

According to @dwijnand, the issue is a bit different from the one in #188. In ScalaJS, it seems, the name setting only contains the plain name, while the ScalaJS-specific suffix gets added only during publishing. Except dbuild resets the publish task to the default value, in order to capture the produced artifacts; in addition, it only checks the name setting in order to, well, find the name. So I have to look into adding explicit support for ScalaJS artifacts, and the related special name mangling.

commented

I expressed myself inprecisely.

To recap, the default behaviour when using Scala.js' cross-build support will:

  • Create two sbt projects, with distinct ids, eg. fooJVM and fooJS
  • But give them the same name, eg. foo
  • Then be default moduleName is defined in terms of name (via normalizedName), so still foo

See:

At some point the end artifactId (as found in the POM's and artefact file names) we do name mangling. Giving us artifactId's such as foo_2.11 and foo_sjs0.6_2.11. I'm not sure exactly where, I tried looking last time and couldn't find it. I meant when "publishing" - I'm not sure it's exactly in the publish task.

commented

@dwijnand Thanks for the clarification! Yes, I use moduleName in dbuild to determine the artifact name, see https://github.com/typesafehub/dbuild/blob/d464e487e4373270315429d850ff253e040947fc/plugin/src/main/scala/com/typesafe/dbuild/plugin/DBuildRunner.scala#L801
I'll track down where exactly the further renaming takes place; I need to mimic that by using the same logic that ScalaJS uses in order to generate the proper artifact information in dbuild.

commented

Scala.js does not override publish, so resetting publish should not be an issue. The way it adds its suffix is through the crossVersion sbt setting, here: https://github.com/scala-js/scala-js/blob/v0.6.13/sbt-plugin/src/main/scala/org/scalajs/sbtplugin/ScalaJSPluginInternal.scala#L991

commented

highly unlikely to ever happen