I apologize in advance if this is convoluted… I’m learning about nexus staging as we go along…
In nexus they have a concept of ‘staging’. What happens is that they create a temporary repository that you can then decide to ‘promote’ or not.
Think in terms of Continuous Delivery. You build 1.0.1 of your app and push it to nexus. You don’t want that going straight to the production repository, so you publish to a dev staging repo. From that you get back a stagingRepositoryId. An example would be myapp-dev-1000. If your acceptance tests pass, you then promote it to UAT. If your UAT tests pass, you release it (which goes into the PROD repo). The world can then see it.
You need that stagingRepositoryId in order to perform the promotion. It is passed into the rest client in the body.
With the maven-publish plugin, you can publish to a standard repo, but there appears to be none of the staging concepts baked in.
Take a look at the nexus-staging-ant-tasks to see the workflow. https://github.com/sonatype/nexus-ant-tasks/tree/master/nexus-staging-ant-tasks
To get around it so far I’m using maven-publish gradle plugin to publish to nexus, then using the ant tasks to promote it.
The problem here is that I have to manually log into the nexus UI to find out what the stagingRepositoryId is and then pass that into the ant tasks to perform the workflow.
I think we can/should enhance the maven-publish plugin to understand those staging capabilities and at a minimum return the properties file like they are doing from the maven and ant plugins:
Otherwise I guess we should have a separate plugin… One that is maven-publish, and another that is nexus-staging (that could contain publish and the workflow, etc…). I already have gradle plugin code working that does the promotions… but there are still big gaps…