Scala-js 1.0.6 does not contains classes

[etorreborre]

1.0.6 is published as a bundle and does not contain classes like 1.0.5

Could you please publish the latest version as a normal jar?

[lrytz]

This might be my bad, I'm taking a look.

[lrytz]

My observations: if I run

> clean
[success] Total time: 0 s, completed Jul 4, 2017 11:04:55 AM
> scala-parser-combinatorsJS/publishLocal
...

$ unzip -l js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
Archive:  js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
      387  07-04-2017 11:05   META-INF/MANIFEST.MF
      122  07-04-2017 11:04   scala-parser-combinators-js.properties
---------                     -------
      509                     2 files

However, with package, the content is there:

> clean
[success] Total time: 0 s, completed Jul 4, 2017 11:05:48 AM
> scala-parser-combinatorsJS/package
...

$ unzip -l js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
Archive:  js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
      396  07-04-2017 11:05   META-INF/MANIFEST.MF
...
     4168  07-04-2017 11:05   scala/util/parsing/combinator/Parsers$Parser$$anon$5.sjsir
     2429  07-04-2017 11:05   scala/util/parsing/combinator/Parsers$$tilde$.sjsir
     2184  07-04-2017 11:05   scala/util/parsing/json/JSONObject$.sjsir
     2784  07-04-2017 11:05   scala/util/parsing/combinator/token/Tokens$ErrorToken$.sjsir
     1404  07-04-2017 11:05   scala/util/parsing/json/JSONType.class
    11781  07-04-2017 11:05   scala/util/parsing/combinator/RegexParsers.class
...

I have very little experience with Scala.js. @sjrd, is the above expected?

[lrytz]

Potentially relevant changes between 1.0.5 and 1.0.6:

• 9b705dd
• 6cac8c3
  • Corresponding changes to scala-module-plugin: scala/sbt-scala-module@v1.0.4...v1.0.8

[sjrd]

is the above expected?

Definitely not. Scala.js jars published on Maven/Bintray/etc. look very much like JVM jars. They just have .sjsir files in addition to .class files. They should not be virtually empty like in your listing above.

[lrytz]

OK, thanks, I'll have to do some digging in sbt :)

[lrytz]

I didn't find the issue. show scala-parser-combinatorsJS/packageBin::mappings (which is shows up as a dependency of package) looks right, but i couldn't figure out from the dependencies of publishLocal how the published jar is biult.

> show scala-parser-combinatorsJS/*:publishLocal::packagedArtifacts
... Artifact(scala-parser-combinators,bundle,jar,None,List(compile),None,Map()) -> /Users/luc/scala/scala-parser-combinators/js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar ...

$ unzip -l /Users/luc/scala/scala-parser-combinators/js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
Archive:  /Users/luc/scala/scala-parser-combinators/js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
      387  07-04-2017 14:55   META-INF/MANIFEST.MF
      122  07-04-2017 14:55   scala-parser-combinators-js.properties
---------                     -------
      509                     2 files

But then I don't know how that jar is built:

> inspect tree scala-parser-combinatorsJS/*:publishLocal::packagedArtifacts
[info] scala-parser-combinatorsJS/*:packagedArtifacts = Task[scala.collection.immutable.Map[sbt.Artifact, java.io.File]]
>

[dwijnand]

Some exploratory notes.

To summarise:

• ✅ package
• ❌ publishLocal

The reason looks like it's because:

• package uses compile:packageBin, while
• publishLocal uses compile:packageBin::packagedArtifact

Why are these different? Because of sbt-osgi - in version 0.7.0 it redefines packageBin::packagedArtifact:

packagedArtifact in (Compile, packageBin) <<=
  (artifact in (Compile, packageBin), OsgiKeys.bundle).identityMap

(source: https://github.com/sbt/sbt-osgi/blob/v0.7.0/src/main/scala/com/typesafe/sbt/osgi/SbtOsgi.scala#L29)

Indeed running compile:osgiBundle creates a osgi bundle with no classfiles or IR files:

$ unzip -l js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
Archive:  js/target/scala-2.12/scala-parser-combinators_sjs0.6_2.12-1.0.7-SNAPSHOT.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
      387  07-04-2017 14:39   META-INF/MANIFEST.MF
      121  07-04-2017 14:39   scala-parser-combinators-js.properties
---------                     -------
      508                     2 files

As a next step I've encouraged @lrytz to upgrade to a more modern sbt-osgi 0.8.0; perhaps it doesn't clash with sbt-scalajs.

[lrytz]

I did my best here, but no success so far.

Here's the branch where I upgrade sbt-scala-module to sbt-osgi 0.9.1: https://github.com/scala/sbt-scala-module/compare/master...lrytz:sbt-osgi-0.9.1?expand=1

@dwijnand there's a strange thing happening: when I add && SbtOsgi to requires, then the buildSettings of my plugin are no longer applied (see comment in the diff above).

Here's a branch of this repo using that new plugin version: https://github.com/scala/scala-parser-combinators/compare/1.0.x...lrytz:sbt-osgi-0.9.1?expand=1

Without adding && SbtOsgi things seem to work. Running scala-parser-combinatorsJVM/publishLocal (the JVM project) gives a small diff in the generated manifest, but probably OK (the Bundle-Name changed for some reason).

diff -u -r b/META-INF/MANIFEST.MF a/META-INF/MANIFEST.MF
--- b/META-INF/MANIFEST.MF	2017-07-05 10:27:04.000000000 +0200
+++ a/META-INF/MANIFEST.MF	2017-07-05 08:26:12.000000000 +0200
@@ -1,8 +1,12 @@
 Manifest-Version: 1.0
-Bnd-LastModified: 1499243224337
+Bnd-LastModified: 1499243172774
+Bundle-Description: scala-parser-combinators
+Bundle-License: http://opensource.org/licenses/BSD-3-Clause;description=
+ BSD 3-clause
 Bundle-ManifestVersion: 2
-Bundle-Name: org.scala-lang.modules.scala-parser-combinators
+Bundle-Name: scala-parser-combinators
 Bundle-SymbolicName: org.scala-lang.modules.scala-parser-combinators
+Bundle-Vendor: org.scala-lang.modules
 Bundle-Version: 1.0.7.SNAPSHOT
 Created-By: 1.8.0_131 (Oracle Corporation)
 Export-Package: scala.util.parsing.combinator;version="1.0.7.SNAPSHOT";u
@@ -26,12 +30,12 @@
  til,scala.util.parsing.combinator,scala.util.parsing.combinator.lexical
  ,scala.util.parsing.combinator.syntactical,scala.util.parsing.combinato
  r.token,scala.util.parsing.input"
-Import-Package: scala;version="[2.12,3)",scala.collection;version="[2.12
- ,3)",scala.collection.generic;version="[2.12,3)",scala.collection.immut
- able;version="[2.12,3)",scala.collection.mutable;version="[2.12,3)",sca
- la.math;version="[2.12,3)",scala.reflect;version="[2.12,3)",scala.runti
- me;version="[2.12,3)",scala.runtime.java8;version="[2.12,3)",scala.sys;
- version="[2.12,3)",scala.util;version="[2.12,3)",scala.util.matching;ve
- rsion="[2.12,3)"
+Import-Package: scala,scala.collection;version="[2.12,3)",scala.collecti
+ on.generic;version="[2.12,3)",scala.collection.immutable;version="[2.12
+ ,3)",scala.collection.mutable;version="[2.12,3)",scala.math;version="[2
+ .12,3)",scala.reflect;version="[2.12,3)",scala.runtime;version="[2.12,3
+ )",scala.runtime.java8;version="[2.12,3)",scala.sys;version="[2.12,3)",
+ scala.util,scala.util.matching;version="[2.12,3)"
 Private-Package: scala-parser-combinators.properties
-Tool: Bnd-2.1.0.20130426-122213
+Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
+Tool: Bnd-2.4.0.201411031534

However, the initial bug is not fixed, running scala-parser-combinatorsJS/publishLocal (on the JS project) still leaves an empty jar.

[dwijnand]

SbtOsgi seems to have been authored to be an AutoPlugin that doesn't auto-trigger. There is no way to force the triggering of a plugin with another plugin. For more info there is a feature request for exactly this, as well as arguments against, at sbt/sbt#2093.

Here's a few possible solutions/notes (so you can pick and choose):

• Enable SbtOsgi, so everything gets triggered.
• Split the ScalaModulePlugin OSGI things into a ScalaModuleOsgiPlugin (with requires SbtOsgi), so that they get applied on any project that enables SbtOsgi.
• Consider removing/splitting scalaModuleSettings to use projectSettings.
• Consider introducing an autoImport so that some names are auto-imported (such as scalaModuleSettings).

[lrytz]

@dwijnand as far as I can tell, the change I mentioned above (https://github.com/scala/sbt-scala-module/compare/master...lrytz:sbt-osgi-0.9.1?expand=1), the SbtOsgi plugin does its work when adding the sbt-scala-module plugin, I get a manifest with OSGi stuff.

What surprised me is that adding && SbtOsgi to requires broke the buildSettings of the sbt-scala-module plugin, but I just left that away and the osgi plugin seems to do its work.

[lrytz]

So to summarize, I think we are fine with the new version of SbtOsgi, we just add its settings to the scalaModuleSettings of our plugin. However, upgrading SbtOsgi didn't solve the conflict with the Scala.js plugin, and we still end up with an (almost) empty sjs-jar.

[etorreborre]

Thanks for still pushing on this issue @lrytz. Would it make sense to remove the Osgi plugin and do a normal release so that we can at least get the latest version of the code officially available?

[lrytz]

I guess OSGi metadata is really unnecessary in an sjs-jar, so we could enable it on the JVM project only. That would be easy enough.

[sjrd]

That would indeed make sense!