Get rid of the extra resolver #21
Comments
|
I would consider this an important issue, because it forces plugins that depend on this one to tell their users to add the resolver too. I'm in the process of adding |
|
Hi @jvican! This issue is not related to publishing to Bintray or Sonatype. It's an issue with the underlying Github library: hub4j/github-api#195. That's one of the reasons I want to migrate to another library (most likely 47deg/github4s): #17. Regarding Bintray publishing: the repo is linked to the community repo sbt-plugin-releases, so if the problem mentioned above was solved, you wouldn't need to add any resolvers, sbt-plugin-releases is included in the default plugin resolver chain. So I don't see any point in changing to Sonatype.
We're using our own release pipeline here, so I think currently it's not an option.
I totally agree. It sucks
Sounds awesome! 👍 I'll be glad to help with it. |
|
Oh, I see, now it makes sense 👍! So, it seems that #17 would take you some time. Have you considered releasing github-api with your organization to Maven Central? It sounds like that would be a time-saving way of fixing this problem. |
Well, I don't want to spend too much time on it. But of course it will. Actually, I made a more thorough review of the available options (see updated #17) and I don't see any perfect one for now. I would actually prefer just to stay with kohsuke/github-api, but solve this pesky resolver issue (btw, I pinged @kohsuke in hub4j/github-api#195, so let's see if he is willing to resolve it).
Several problems with it: using maven, setting up publishing to Maven Central (I never used it) and mainly that the problem is about some dependency of kohsuke/github-api, not the library itself. |
This is the best solution short term: publish a farjar in an extra artifact with a I think this should be easy enough to set up with By the way, thanks for your attention to this! 😄 |
laughedelic
changed the title
|
On a second thought it's not a bad idea indeed 🤔 It is a good short-term solution.
It's already setup by the nice-sbt-settings plugin 👌 So I just need to add assembled jar to publishing. I'll try it now. |
No problem 😉 I'm interested in solving this issue in particular and moving this plugin forward in general. As I told you elsewhere, I believe that release notes are an essential part of every release. And visibility of release notes is important for happy users 😊 This is the purpose of this plugin. |
|
Perfect! I'm already depending on this plugin in |
|
Done: #22 (comment) |
|
It looks like this approach is not working: Changing the value of |
|
I believe one way to get away with adding the new resolver is to add the leaf sbt plugin that depends on |
Haha! I understand now: Another way to solve this would be to publish another fat artifact which doesn't have any dependencies in the |
|
Yeah, in short If I depend on the fat jar of |
|
@jvican Good news! I just released v0.6.0, which should work well without any extra resolvers or fat-jars. It seems that the problem has been solved upstream: hub4j/github-api#195 (comment). |
|
That's good news, thank you for keeping me in the loop. |
I see that you release to Bintray instead of Sonatype. I think it would be better to release directly to Sonatype so that I don't have to add yet another resolver to my build 😄.
You could also use
sbt-release-early-> https://github.com/scalacenter/sbt-release-early.The text was updated successfully, but these errors were encountered: