Romain Grécourt wrote on 10/17/2018 05:20 PM:
Romain Grécourt wrote
on 10/17/18 04:23 PM:
> On Wed, Oct 17, 2018 at 4:09 PM Bill Shannon <bill.shannon@xxxxxxxxxx
> <mailto:bill.shannon@xxxxxxxxxx>>
wrote:
>
> No one ever did answer this question so here's my
guess...
>
> The "snapshots" profile should be used only what
pushing out SNAPSHOT artifacts.
>
> The "staging" profile should be used when staging
a final release for
> review, before finally releasing it.
>
> The "oss-release" profile should be used only
when doing a final release
> of a reviewed and approved artifact.
>
>
> The "oss-release" profile is the only one that
signs the artifacts.
>
>
> This is used for any "Maven release" that goes to
Maven Central, final or not final.
I didn't think SNAPSHOT releases needed to be signed.
SNAPSHOT artifacts are not deployed with a Maven
Release.
A simple "mvn deploy" is usually enough.
I think we're using the same terminology differently.
I think of anything pushed to a Maven repository to be a "release".
I guess you only consider non-SNAPSHOT versions to be a "release".
I used "Maven release" to refer to the Maven release workflow (think maven-release-plugin):
- prepare: (update version, create tag)
- perform: (checkout tag, build + deploy)
Note that the maven-release-plugin enforces release version (i.e non-SNAPSHOT versions).
I.e,
- you "push" a SNAPSHOT artifact to a Maven repository by doing just a "mvn deploy" (NOT using the maven-release-plugin).
- you "push" a non-SNAPSHOT artifact to a Maven repository by doing a "Maven release" (using the maven-release-plugin).
Maven Central is a "release version" only repository, it does not contain SNAPSHOT versions.
It has some special requirements (GPG signatures, javadoc.jar, sources.jar).
The oss-release profile defines a set of plugin executions to fulfill those requirements (gpg-plugin, javadoc-plugin, sources-plugin).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<mavenExecutorId>forked-path</mavenExecutorId>
<useReleaseProfile>false</useReleaseProfile>
<arguments>-Poss-release ${release.arguments}</arguments>
</configuration>
</plugin>
This means you don't have to specify the oss-release profile explicitly.
I.e When doing "release:prepare" or "release:perform", the maven-release-plugin will fork itself and the oss-release profile will be set of the fork Maven process.
>
>
> If I'm using the nexus-staging-maven-plugin to
stage my release so that
> it can be verified, and then to later close the
staging repository and
> finally release it, do I need to use the
"oss-release" profile to do that?
>
>
> The "oss-release" profile adds a lifecycle (i.e
plugin executions) that is not
> desirable for this use-case.
> The base configuration of the plugin can be done in
the default profile (i.e no
> profile).
I don't understand.
If I'm staging my release for review, don't I want to
include the source jar
file? Don't I want to sign the artifacts so when the
release is approved I
can just "release" the repo?
You need to use the oss-release profile to perform a
maven release.
In fact you can't close a staging repository without
using that profile, otherwise you get validation error
(Maven central requirements: source.jar javadoc.jar gpg
signatures).
Then what's the point of the "staging" profile? If I push something
using that profile, it won't be signed, so I won't be able to close
the staging repository, right?
This profile is not used to "push" but to "pull".
Once you have run a Maven release and you have a "closed" staging repository, you can use this profile to pull/consume the artifacts from the staging repository.
However you do not want to use the release profile to
automate the 2nd part of the nexus workflow (i.e
nexus-staging:rc-release)
Do the profiles have any effect when just invoking "mvn
nexus-staging:something"? I assumed they were unnecessary but also
harmless in this case. I assumed they only really mattered when
doing "mvn deploy".
Right, this will generate harmless noise.
>
> If so, I'm not sure when the "staging" profile
would be used.
>
>
> IIUC the current direction seems to decouple the
nexus workflow in 2 steps:
> - deploy to a staging repository and close the
staging repository
> - release the staging repository once
reviewed/approved
>
> The staging profile configures the staging repository
group for oss.sonatype.org
> <http://oss.sonatype.org>.
(https://oss.sonatype.org/content/groups/staging/)
> I.e If activated, one can consume artifacts from any
closed staging repository.
>
> If the review/approval depends on automated test
suites, they will likely need
> to consume the artifacts from the staging
repository.
So if I deploy them using oss-release and close the repo,
but don't release
it, what happens? Can I download the artifacts from some
staging area and
test them before releasing the repo?
You will use the staging profile to enable the staging
group repository in your project.
I'm still not getting it.
I see that the staging profile will target the deployment to a
different repository group than the oss-release profile.
The target deployment repository is configured in a pom.xml with "distributionManagement".
The EE4 parent pom has only one such configuration, profiles do not alter this at all.
<distributionManagement>
<snapshotRepository>
<id>ossrh</id>
<name>Sonatype Nexus Snapshots</name>
<url>${sonatypeOssDistMgmtSnapshotsUrl}</url>
</snapshotRepository>
<repository>
<id>ossrh</id>
<name>Sonatype Nexus Releases</name>
<url>${sonatypeOssDistMgmtReleasesUrl}</url>
</repository>
</distributionManagement>
The "snapshots" and "staging" profile actually configure a repository to enable consuming/pulling for that repository, not deploying/pushing to it.
<repositories>
<repository>
<id>sonatype-nexus-snapshots</id>
<name>Sonatype Nexus Snapshots</name>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>sonatype-nexus-snapshots</id>
<name>Sonatype Nexus Snapshots</name>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
What I don't understand is why I would ever want to target something
to that other repository group. The stuff I put there won't be
signed, so I can't ultimately "release" it. What would I use it
for? Why wouldn't I just use the oss-release profile and target
that repository group, close it, but not release it until after it
has been tested and approved?
I don't understand how to get signed artifacts into a
staging area so that
they can just be "released" after being tested and
approved, without needing
to recreate the artifacts.
Not sure where the confusion is.
Step1: Do a Maven release using -Poss-release.
After that, you will have a closed staging repository
with all your artifacts (signed and everything).
Step2: Get the approval, release the staging
repository, wait for 10min for the artifacts to show on
Maven Central.
Right, so what's the purpose of the "staging" profile?
Consume/Pull from closed staging repositories.
