sbt-sonatype 3 does not work with sbt-dynver

Question

sbt-sonatype 3 does not work with sbt-dynver

Atry opened this issue 5 years ago · comments

I use sbt-sonatype with sbt-dynver, to publish dynamic versions (e.g. 1.0.0+3-1234abcd ) to Maven Central.

Originally in sbt-sonatype 2.x, I used the command sbt ++$TRAVIS_SCALA_VERSION "sonatypeOpen \"Travis Job $TRAVIS_JOB_NAME $TRAVIS_JOB_NUMBER ($TRAVIS_JOB_WEB_URL)\"" publishSigned sonatypeRelease on Travis CI to publish a release.

After I upgrade sbt-sonatype to 3.4, I use the command sbt "set sonatypeSessionName := \"Travis Job $TRAVIS_JOB_NAME $TRAVIS_JOB_NUMBER ($TRAVIS_JOB_WEB_URL)\"" "set every publishTo := sonatypePublishToBundle.value" publishSigned sonatypeBundleRelease instead.

Unfortunately I got an error message of 400: Bad Request because sonatypePublishToBundle is sonatypeSnapshots, which does not support dynamic versions.

Taro L. Saito · Answer 1 · Sat Sep 07 2019 03:17:49 GMT+0800 (China Standard Time)

It seems Sonatype API rejects bundles that contain dynamic version files like project-1.0.0+3-1234abcd.jar.

In this case, we need to fall back to the previous step (it still works in sbt-sonatype 3.x):

Setting publishTo := sonatypePublishTo.value (for direct upload)
sonatypePrepare
+publishSigned
sonatypeReleaseAll

I'll look into more details to see if there is any workaround.

Yang, Bo · Answer 2 · Sat Sep 07 2019 03:19:53 GMT+0800 (China Standard Time)

sbt-dynver set isSnapshot to true for dynamic versions, which do not end with -SNAPSHOT.

Taro L. Saito · Answer 3 · Sat Sep 07 2019 03:23:26 GMT+0800 (China Standard Time)

ah. OK. Then using isVersionStable will be more appropriate for sbt-dynver user.

Yang, Bo · Answer 4 · Sat Sep 07 2019 03:25:50 GMT+0800 (China Standard Time)

You may be not willing to depend on sbt-dynver. Let's just check the version suffix. See #96

Taro L. Saito · Answer 5 · Sat Sep 07 2019 03:29:07 GMT+0800 (China Standard Time)

Ok. #96 is merged. The next step is to test whether the bundle can be uploaded properly.

Taro L. Saito · Answer 6 · Sat Sep 07 2019 03:31:54 GMT+0800 (China Standard Time)

ok. It seemed the comment #95 (comment) was my misunderstanding. I can properly upload artifacts that use sbt-dynver.

Taro L. Saito · Answer 7 · Sat Sep 07 2019 03:35:56 GMT+0800 (China Standard Time)

I'm releasing sbt-sonatype-3.6 with the fix in #96 now.

Thank you for the fix!

Yang, Bo · Answer 8 · Mon Sep 09 2019 04:34:52 GMT+0800 (China Standard Time)

I just wonder if we could skip the snapshot version check for sonatypePublishToBundle, allowing for bundle uploading for any versions, no matter whether they end with -SNAPSHOT.

Yang, Bo · Answer 9 · Mon Sep 09 2019 04:38:38 GMT+0800 (China Standard Time)

@xerial What do you think?

Taro L. Saito · Answer 10 · Mon Sep 09 2019 14:36:44 GMT+0800 (China Standard Time)

Uploading jars with -SNAPSHOT suffix is possible with bundle upload, but the validation will anyway fail. So there is no point in allowing that operation.

And also there seems no Sonatype API to upload snapshot versions as a bundle to Sonatype Snapshot repository.

Yang, Bo · Answer 11 · Mon Sep 09 2019 14:39:20 GMT+0800 (China Standard Time)

Would it make more sense if returning None for -SNAPSHOT versions? Taro L. Saito <notifications@github.com>于2019年9月8日周日下午11:36写道：

…

Uploading jars with -SNAPSHOT suffix is possible with bundle upload, but the validation will anyway fail. So there is no point in allowing that operation. And also there seems no Sonatype API to upload snapshot versions as a bundle. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AAES3OVV7Y7TY2YNJYL3SL3QIXVH3A5CNFSM4IUMDK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GMVSY#issuecomment-529320651>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OUE4BKQVDAO5FIBAF3QIXVH3ANCNFSM4IUMDK6A> .

Taro L. Saito · Answer 12 · Mon Sep 09 2019 14:42:41 GMT+0800 (China Standard Time)

Unfortunately, publish and publishSigned share the same publishTo setting, so returning None is not good for Snapshot releases.

Yang, Bo · Answer 13 · Mon Sep 09 2019 14:46:34 GMT+0800 (China Standard Time)

I just feel sonatypePublishToBundle should be be an invalid value if bundle uploading is not supported under current settings. Taro L. Saito <notifications@github.com>于2019年9月8日周日下午11:42写道：

…

Unfortunately, publish and publishSigned share the same publishTo setting, so returning None is not good for Snapshot releases. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AAES3OS5KQAAYIJ5TEWOH7LQIXV6FA5CNFSM4IUMDK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GNBRY#issuecomment-529322183>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OUFDYREFOZD5TYWJYTQIXV6FANCNFSM4IUMDK6A> .

Taro L. Saito · Answer 14 · Mon Sep 09 2019 15:25:19 GMT+0800 (China Standard Time)

As long as we ask users to use publishTo := sonatypePublishToBundle.value, returning None for this value would not work. Othewise, we need to ask users to set settings like this:

publishTo := {
   if(version.value.endsWith("-SNAPSHOT")) 
      Opts(Sonatype.snapshot..)
   else 
      Opts(local resolver to staging folder) 
}

It's a design choice and I prefer a simpler one. Advanced users just can specify a local staging folder or arbitrary snapshot repository for publishTo.

Yang, Bo · Answer 15 · Mon Sep 09 2019 15:31:26 GMT+0800 (China Standard Time)

How about creating an optional plugin, say, SonatypeBundleUploading, instead of asking users to set publishTo manually? Taro L. Saito <notifications@github.com>于2019年9月9日周一上午12:25写道：

…

As long as we ask users to use publishTo := sonatypePublishToBundle.value, returning None for this value would not work. Othewise, we need to ask users to set settings like this: publishTo := { if(version.value.endsWith("-SNAPSHOT")) Opts(Sonatype.snapshot..) else Opts(local resolver to staging folder) } It's a design choice and I prefer a simpler one. Advanced users just can specify a local staging folder or arbitrary snapshot repository for publishTo. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AAES3OQQNF2KQJBA3224KTTQIX26DA5CNFSM4IUMDK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GQBLA#issuecomment-529334444>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OQKC54T4BABXOFNNRTQIX26DANCNFSM4IUMDK6A> .

Taro L. Saito · Answer 16 · Mon Sep 09 2019 16:08:10 GMT+0800 (China Standard Time)

There are various types of build settings (including parallel build), which cannot be covered by a single task:
https://github.com/xerial/sbt-sonatype#advanced-build-settings

Some people (including your case #26) want to publish each sub-module individually to different sonatype profile, but majorities of the case would be aggregating all sub-modules artifacts into a single staging folder.

A tricky part is to tweak publish(Signed)To setting internally without explicitly modifying it. We need to use sbt commands, but sbt commands cannot be run for each project. So we need to use Tasks to define things like SonatypeBundleUploading task (or command). However, calling a task from commands also can be tricky code.

I think implementing it is too much (at least for me for now).

If sbt has a command like publishStaging and publishStagingAggregate, then the role of sbt-sonatype will be much simpler. (cc: @dwijnand, @eed3si9n)

Yang, Bo · Answer 17 · Mon Sep 09 2019 23:54:56 GMT+0800 (China Standard Time)

There is a publishM2, but not signed version Taro L. Saito <notifications@github.com>于2019年9月9日周一上午1:08写道：

…

There are various types of build settings (including parallel build), which cannot be covered by a single task: https://github.com/xerial/sbt-sonatype#advanced-build-settings Some people (including your case #26 <#26>) want to publish each sub-module individually to different sonatype profile, but majorities of the case would be aggregating all sub-modules artifacts into a single staging folder. A tricky part is to tweak publish(Signed)To setting internally without explicitely modifying it we need to use sbt commands, but sbt commands cannot be run for each project. So we need to use Tasks to define things like SonatypeBundleUploading task (or command). A calling a task from commands also can be tricky for now. I think implementing it is too much (at least for me for now). If sbt has a command like publishStaging and publishStagingAggregate, then the role of sbt-sonatype will be much simpler. (cc: @dwijnand <https://github.com/dwijnand>, @eed3si9n <https://github.com/eed3si9n>) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AAES3OQBYBCDEB6M4L5YO2TQIX76XA5CNFSM4IUMDK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GTOFA#issuecomment-529348372>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OXXNBDT5FPYDGFZ2STQIX76XANCNFSM4IUMDK6A> .

Taro L. Saito · Answer 18 · Tue Sep 10 2019 02:08:59 GMT+0800 (China Standard Time)

Added a proposal to add publishStaging task to sbt: https://discuss.lightbend.com/t/idea-add-publishstaging-task-to-sbt-for-creating-bundles-for-sonatype-upload/5020

Dale Wijnand · Answer 19 · Mon Sep 16 2019 19:06:59 GMT+0800 (China Standard Time)

You may be not willing to depend on sbt-dynver. Let's just check the version suffix. See #96

sbt identifies keys by structural equality.

So you can just define your own isVersionStable key and use it:

val isVersionStable = settingKey[Boolean]("")

// usage:
val result: Option[Boolean] = isVersionStable.?.value
// Using `?` in case sbt-dynver isn't present:
// None most probably means it's not