gilcloud / sbt-gitlab

sbt plugin to allow dependency resolution and artifact publishing for gitlab
Apache License 2.0
26 stars 19 forks source link

Removes reliance on Okhttp3 for sbt 1.7+ support #33

Closed listba closed 1 year ago

listba commented 1 year ago

The plugin originally relied on the RequestInterceptor capabilities that were part of the OKHttp3 client backed exposed via sbt.CustomHttp. Additionally it also relied on the GigaHorseURLHandler to leverage the OkHttp3 client. Unfortunately all of this was removed as part of the SBT 1.7.0 release (see pr: https://github.com/sbt/librarymanagement/pull/399).

The OkHttp3 client backed was swapped out for the the Apache HTTP HttpAsyncClient. But as far as i can tell it does not have the same RequestInterceptor capabilities. additionally with the removal of the GigaHorseUrlHandler There isnt any way (from what I could tell) that actually leveraged or used the Apache gigahorse client.

So to get this to work with sbt 1.7.0 I extended the BasicURLHandler that the SBT plugin is using as the default UrlHandler and added logic to add the gitlab credential headers to the getUrlInfo, download, and upload requests when the host name matches provided (or default) gitlab hostname.

From my limited testing capabilities I was able to both publish to and pull from our private self hosted gitlab repo on sbt 1.7 using the plugin without having to make any changes to my sbt files.

Additionally I pulled in the change from issue #25 / pr #27 since there have been a few issues with people naming their resolver gitlab-maven and the publishResolver overwrites it

Note: I closed the original pr (31) and reopened it because i pushed changes to the old branch that were for my fork. Reopening in case you still want this fix.

polentino commented 1 year ago

@gilandose would it be possible to review this PR and release it, if good enough for publishing? 🙏

gilandose commented 1 year ago

thanks a lot, I'm not using this so much in my job anymore, but I'll get a release cut