scala/scala-java8-compat

Incorrect OSGi manifest

skitt opened this issue · 20 comments

skitt commented

The JAR for version 0.8.0 had a fully-populated manifest, generated by BND; but 0.9.0 doesn’t, nor does the JAR produced by building HEAD manually. I haven’t figured out why that is yet...

It does look like the OSGi bits are not being propagated through scala-module-plugin, but I have zero clue as to why.

This is blocking OpenDaylight's adoption of Scala 2.13.0 (https://jira.opendaylight.org/browse/ODLPARENT-204), as there is only 0.9.0 for 2.13.0. Would it be possible to spin v0.8.0 for 2.13.0?

Would it be possible to spin v0.8.0 for 2.13.0?

Not possible, because the changes, made in association with the 2.13 collections changes, were thoroughgoing.

Is scala-java8-compat the only affected module, or are the 2.13 versions of all of the modules all affected? That would narrow down whether we need to fix something in sbt-scala-module, or whether it's just this repo that needs a fix.

Is scala-java8-compat the only affected module, or are the 2.13 versions of all of the modules all affected?

I quickly checked scala-async, it is affected, too. Looking at its versions, _2.12-0.9.7 is affected (no OSGi headers), _2.12-0.9.6 is okay. Looking at the diff between those versions it switched from sbt-osgi-0.6.0 to scala-module-plugin-1.0.8, so yeah, this is smells like sbt-scala-module.

A few more datapoints:

  • scala-swing_2.12 2.0.1 is fine, 2.0.2 (and later) is not -- there is a switch from scala-module-plugin-1.0.8 to sbt-scala-module-1.0.13
  • scala-xml_2.12 1.2.0 is fine but its using .jvmSettings() to set OsgiKeys.

I am not sure what to make of this (not a Scala/SBT person, unfortuantely)

@szeiger you have the misfortune of having done OSGi things, any idea what's going wrong here?

perhaps there are clues, or even a solution, in scala/scala-collection-compat#226 ? /cc @dwijnand

volunteer to PR the fix?

@SethTisue Hi, i ran build.sh on master from 12.2.2020 and the OSGi manifest seems to be generated in the locally produced jar file. I used clean new VM to check it (ubuntu 18.04.4 LTS, openjdk 1.8.0_242, scala 2.13.1, sbt 1.3.8)

I ran scalaJava8Compat/publishLocal on master and then inspected the resulting ~/.ivy2/local/org.scala-lang.modules/scala-java8-compat_2.13/0.9.0+83-75c255dd-SNAPSHOT/bundles/scala-java8-compat_2.13.jar and also compared it to the org/scala-lang/modules/scala-java8-compat_2.12/0.8.0/scala-java8-compat_2.12-0.8.0.jar in my Coursier cache and indeed, all seems well 🤷‍♂️

thanks @fgschwan

but then, hmm, also I don't see anything wrong with the 0.9.0 JAR

@skitt @rovarga can you be very detailed and specific about what is wrong with the 0.9.0 JARs, in your view?

skitt commented

@skitt @rovarga can you be very detailed and specific about what is wrong with the 0.9.0 JARs, in your view?

scala-java8-compat_2.12-0.8.0.jar has a correctly-populated META-INF/MANIFEST.MF (from the OSGi perspective), notably with the relevant Export-Package and Import-Package entries. scala-java8-compat_2.13-0.9.0.jar doesn’t.

Thanks, I'll take a second look

@SethTisue maybe it was some transient issue with upstream plugins (or whatever) at the time when 0.9.0 was built -- perhaps all that's needed is to release current state of the branch as 0.9.1 and all will be fine :)

let's roll 0.9.1-RC1 and see. if it looks good, we'll re-roll as 0.9.1

0.9.1-RC1 artifacts should be on Maven Central soon (unless something goes wrong over at their end, which seems to happen pretty often). once they arrive, @skitt @rovarga let me know if they look good to you

@SethTisue from a brief look both 2.12 and 2.13 artifacts look okay. Smoke test to use 2.12-0.9.1-RC1 passed here: https://jenkins.opendaylight.org/releng/job/odlparent-maven-verify-master-mvn35-openjdk11/281/ , so I think we're good.

an OSGi problem fixed itself?! perhaps there is a God after all