Romain Grécourt wrote on 10/16/18 04:08 PM:
Romain Grécourt wrote on 10/12/18
01:06 PM:
Have a look at the
nexus-staging-maven-plugin.
There's way too many options and choices there. I'm
really hoping someone else who really understands this
stuff has figured out exactly how to do this for our
Eclipse projects.
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
</configuration>
</plugin>
You can configure the plugin to
automatically release the staging repository
(autoReleaseAfterClose=true).
I.e, this makes the nexus workflow
transparent.
I assume we
don't want to do this because we
need to wait for Release Review approval before
releasing the staged artifacts.
You could also implement the workflow
manually. (skipStagingRepositoryClose=true)
I assume this is what we want. Is this not the default?
The way I understand it the default configuration of
the plugin will leave with a closed staging repository.
Is there some reason I shouldn't want it to be closed
automatically? As long as it's not released, that seems fine.
What can I do with it when it's not closed, other than close it?
You can update the content of the staging repository, i.e deploy more artifacts, delete artifacts.
It would look like something like this:
# Create the nexus staging repository
STAGING_DESC="Project ACME
v${FULL_VERSION}"
mvn nexus-staging:rc-open \
-DstagingProfileId=6026dab46eed94 \
-DstagingDescription="${STAGING_DESC}"
Where does the stagingProfileId come from?
Of course I had to create a Jenkins job to use rc-list-profiles.
:D
I
got this:
[INFO] * Connected to Nexus at https://oss.sonatype.org:443/, is version 2.14.10-01 and edition "Professional"
[INFO] Getting list of available staging profiles...
[INFO]
[INFO] ID Mode Name
[INFO] 7edbe315063867 BOTH Central Bundles
[INFO] 70fc011e3d589e BOTH jakarta.activation
Does that mean I can hard code "70fc011e3d589e" in my script and
never need to change it (as long as my groupId doesn't change)?
Yes.
Unless for some reason the staging profile is re-created for the same groupId.
How often do I need to create the staging repository?
Once ever? Every time I want to stage something new?
Every time you deploy. Without using this plugin, nexus
creates one on the fly.
This is why on
maven.java.net you had to go
to nexus and then close/release.
STAGING_REPO_ID=$(mvn
nexus-staging:rc-list | \
egrep "^\[INFO\] orgacme\-[0-9]+[
]+OPEN[ ]+${STAGING_DESC}" | \
awk '{print $2}' | head -1)
What is "orgacme" above?
This is the profile name. I got that value with
rc-list-profiles (see above).
In my case it's "jakartaactivation" (no dots). I suppose it's
derived from the groupId?
Yes.
# Perform deployment
mvn deploy
-DstagingRepositoryId=${STAGING_REPO_ID}
# Close and release the nexus staging
repository
mvn nexus-staging:rc-close
nexus-staging:rc-release \
-DstagingRepositoryId=${STAGING_REPO_ID} \
-DstagingDescription="${STAGING_DESC}"
Can I put the above in a Jenkins job separate from the
"mvn deploy" command? I'm not clear on what the
lifetime is of the value in STAGING_REPO_ID. If I
compute it once in the "mvn deploy" job and again in the
"rc-release" job, will it have the same value?
Yes, you could automate the workflow with a difference
job.
Note that here I'm expecting only one staging
repository so I grab the first one.
We could think of a convention in the staging
repository description and match that with a parameter on
the job.
E.g This job takes a version as parameter and the
script uses that to match the right repository and
complete the workflow.
Can there be multiple staging repos for the same artifact?
An artifact (GAV) has to be unique.
If you attempt to deploy an artifact that already exists, you won't be able to close the staging repository.
However, if you have duplicate artifacts in different "open" staging repository, you will be able to close the first.
The 2nd one will fail with a validation error about the duplicate GAV.
If I forget to release or drop one, that would be a problem. I
guess I should iterate over all the repos and close drop them all
before creating a new one.
Assuming there is only one release at a time may not be true if there are multiple active code lines.
My take on this would be to simply match the right repository based on the description.
Ok, I'm getting pretty close to getting this working (I think). Now
I just need to get permission to deploy org.eclipse.activation and
org.eclipse.mail groupIds (since we seem to have decided to stop
using com.sun.*).
