-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DCA11Y-1145 Make project releaseable #11
DCA11Y-1145 Make project releaseable #11
Conversation
Our release scripts run this and this will cause warnings
Avoid mixed releases
We don't need to change the groupId, we don't do it for our other forks. This has the benefit of being discoverable by the community in Maven repository listing sites and making it easy to use Renovate to suggest replacing existing non-fork with forked versions. |
The benefits make sense, however I have some reservations about the feasibility. (Internal links follow, sorry.) First because of the guide at https://hello.atlassian.net/wiki/spaces/OSP/pages/791250012/HOWTO+Publish+an+open+source+project+on+Maven+Central that says
Second because the buildeng team emphasized it: https://atlassian.slack.com/archives/CFG89A465/p1726782469523919?thread_ts=1726760008.185449&cid=CFG89A465
Third because when I tried to publish the artifact with the current groupId during work on #10, I got an error:
But with changed groupId, the error went away. So my question is - if we do throw away that piece of investigation, how are we making sure that the release will work? |
Get a 409 when trying to deploy otherwise
I'm satisfied with that answer to the "do we need to change groupId?" question, thanks. :) |
This prepares the POMs to be releaseable in the same manner as we've done for Spring, Velocity, and Selenium forks we own in DC.