Hi <@U03N1E342B0>, where do we stand with the Mave...
# wiremock-java
o
Hi @Tom, where do we stand with the Maven Central structure at the moment? Did you reserve
org.wiremock
at some point, or is it up for grabs? I think it would be nice to document the structure for the package group and allow other contributors like @Dirk Bolte to release there
d
are the secrets for sonatype configured on organizational level + can I "just copy" the publishing configuration from wiremock?
t
We need to do some work on this. Currently only I have access to the Sonatype keys, which isn’t a great situation.
o
I think we want to have something on a per package basis. We could also use GitHub packages as the main repository and raise a request to Sonatype to mirror that
^ @Tom WDYT? Maybe it would be the best option if we want to maintain some kind of a permission model
t
Yeah, if we can get Sonatype to mirror GH that might be a easier to live with than trying to make it work in Nexus
d
ok - will adapt the publishing part of the extension to push to GH then.
o
I am exploring the options ATM
@Dirk Bolte @Tom from your points of view, how critical is it to use Maven Central for the extensions and libraries at all? I see some benefits for WireMock Core to simplify the startup, but for the whole ecosystem it's likely to be a pain It's quite easy to synchronize GitHub Packages to Maven Central, but if and only if we have the compliant artifacts including GPG signing & metadata. It is generally a good thing to do but it will definitely require some aux GitHub Actions
d
Personally, I just need to have a repository to add to maven/gradle. Having it on maven central is pretty convenient and increase acceptance for extensions in general, but adding a custom repo for this extension would definitely work for the time being.
t
We ought to start using Actions to publish artifacts anyway, so how about we get a service account set up by Sonatype, put the credentials in the wiremock GH org and then any projects we host can set up publishing actions to the
org.wiremock
group?
o
If the credentials are free-to-use by any maintainer, they can be accidentally leaked or intentionally stolen by any user with Write permissions to GitHub actions, and then used to deploy a malicious version. So we would need to set up some guardrails about usage of these credentials, ideally by making the release pipeline fully protected from tinkering
Also includes all Gradle/Maven plugins that would have access to the environment
t
I presume there’s some precedent around how to do this? A service account per project?
o
A service account per project?
Ideally yes
t
As far as you know do we just submit a JIRA ticket to get supplementary accounts created?
o
yes