OSGi-fy the published incremental compiler artifacts #7
Comments
Hmm... Can you outline your osgi version scheme you use now? |
Here is the current definition of sbt osgi version we inject while OSGi-fying Zinc. However, I think the versioning scheme we currently use isn't ideal, and I'd like to suggest a better one. Here is my take at this:
Where Note that "Releases", "Milestones" and "RCs" are built against stable (i.e., tagged) Scala and sbt branches, i.e., we never want to build releases on top of a SNAPSHOT. While SNAPSHOTS are of course built on top of Scala SNAPSHOTS. One more thing, the proposed OSGi versioning scheme cotains no reference of the used Scala version, because the natural place for that information is the MANIFEST. Meaning that we should fix this ticket together with #3. |
@jsuereth ping :) |
:) Yeah. I'm planning to get to this, but I need to get @skyluc his sbt-rc patch before I head out. If I'm lucky, I'll have time this next week to get this for you. You suggestion looks great, i'll just have to encode the logic into the build. One issue on git-hash is I'll have to encode that on the sbt side so it makes it over to sbt-republish. So that just means it'll be a bit longer until it shows up. |
@jsuereth Awesome. Just wanted to get your feedback on the versioning scheme. I'm glad you like it! |
Hey @jsuereth we could really use this info (specially the git hash) in debugging issues like this one: Scala IDE and Java 1.8 "Unknown constant: 18" |
To bundle the incremental compiler artifacts inside the Scala IDE we currently need to generate a MANIFEST. One additional point that complexify our builds a bit is to craft a proper osgi version, which of course we wouldn't need to do if the published incremental compiler artifacts where already OSGi-ready.
The text was updated successfully, but these errors were encountered: