sbt-sonatype 3 does not work with sbt-dynver

[Atry]

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.

[xerial]

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.

[Atry]

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

[xerial]

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

[Atry]

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

[xerial]

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

[xerial]

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

[xerial]

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

Thank you for the fix!

[Atry]

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.

[Atry]

@xerial What do you think?

[xerial]

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.

[Atry]

Would it make more sense if returning None for -SNAPSHOT versions? Taro L. Saito <[email protected]>于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> .

[xerial]

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

[Atry]

I just feel sonatypePublishToBundle should be be an invalid value if bundle uploading is not supported under current settings. Taro L. Saito <[email protected]>于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> .

[xerial]

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.

[Atry]

How about creating an optional plugin, say, SonatypeBundleUploading, instead of asking users to set publishTo manually? Taro L. Saito <[email protected]>于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> .

[xerial]

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)

[Atry]

There is a publishM2, but not signed version Taro L. Saito <[email protected]>于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> .

[xerial]

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

[dwijnand]

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