Use Scala modules for 2.11 #3
Comments
|
Hmm, I may need some more info. What does the cross versioning look like for the snapshot scala? |
|
as soon as scala/scala#2855 is merged, scala snapshots will no longer contain scala-xml nor scala-parser-combinators |
|
right, how/where can I get them? |
|
|
it's the %% that has me worried for these integration builds. I assume everything is fine in testing, so I'll try to update this in the dbuild scripts. |
|
Well, the scripts override the binary version of org.scala-lang.modules to be the one they're published under. |
|
Yeah.... this is quite the rube goldberg device. I may need you to sit with my via skype sometime and walk me through what we're doing here. It seems I've been too far removed, and this hackery has advanced sufficiently beyond my ability to reason through it quickly. Either that or I need more coffee. |
|
I agree we must simplify these scripts. If the the sbt experts can't parse them, we're in trouble. |
Combined with: When building, if I have to jump through loops to figure out which versions you're publishing and which you aren't, we're in trouble. Again, if everything were in dbuild, great. Since the IDE team doesn't want us to rebuild Scala + Modules in our build (which would keep our build safer), I need to know how you plan to publish-release these modules. MAYBE, (if you're not already doing it), could we include the sbt building + publishing in your current dbuild? If not, maybe we can switch to using dbuilds cache between builds and we can alter our build to "build scala" unless it's found in dbuild's "is the SHA already build?" cache. Then for PR validation we won't rebuild Scala, just grab the existing JARs from your other job. In either case, the current solution leaves a lot to be desired. I do not want to have this issue reopen on every scala Milestone because we can't abstract out these module versions in some sane fashion. |
|
Just stay calm and embrace the modules. Here's a list of the current versions we're using for each module (scala/scala#2855 will update them): A dbuild is planned for these modules soon. Going as fast as I can here. We already build Scala only once per commit and reuse the artifacts. We don't build the external modules during Scala PR validation yet, though. There's no need, as we're trying to experience what full binary compatibility would entail by building modules once every milestone, and enforcing binary compatibility between each release. I've booked a meeting in your calendar next Tuesday to discuss this. |
|
Cool! Again, as long as I have a reasonable way to consume them. Ideally, we can make dbuild aware of the results without having to use either Ivy or rebuild things, if we're using it initially. Look forward to the meeting. |
|
Ugh! I accidentally deleted my comment. Could you paste it from your email? The gist: I've started fixing this issue at https://github.com/adriaanm/sbt-builds-for-ide/blob/master/sbt-on-2.11.x by porting my old solution from scala/jenkins-scripts#23, so that I can merge scala/scala#2855. It fails because the doc task can't find xml. repro: |
|
Ok, got it: To repro: cd ~/git && git clone https://github.com/scala/jenkins-scripts.git [info] [info] Set current project to SBinary Parent (in build file:/Users/adriaan/jenkins-staging/pr2855/sbt-builds-for-ide/target-0.6.4-josh-hack-1/project-builds/sbinary-74fbba46b1cd830f4f9280457afe5e36536b34bd/) |
|
Ok, this should be fixed in the new 2.11 nightlies. |
- The stdlib error mentioned: typesafehub/sbt-builds-for-ide#3 (comment)
Since 2.11.0-M4, Scala cross-publishes scala-xml and scala-combinator-parsers as separate modules under org.scala-lang.modules. The dbuild script should reflect that.
The text was updated successfully, but these errors were encountered: