Romain Grécourt wrote on 10/18/18 04:26 PM:
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).
I don't normally use the maven-release-plugin. I'm just doing "mvn
deploy" and managing the other aspects of the release process
myself. At least I had a cookbook for how to do that at
java.net.
>
>
> 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.
Hmmm... Ok, let's see if I understand this...
Project A uses the "oss-release" profile to deploy a non-SNAPSHOT
release to a staging repository and closes the repository but
doesn't release it.
Project B depends on Project A and uses the "staging" profile when
building
so that the build of Project B will be able to pick up the staged
artifacts from Project A.
Project B then uses the "oss-release" profile to deploy to a staging
repository.
When both Project A and Project B are approved, the two staging
repositories can then be released.
Is that right?
Yes, this is correct.
Though, project A could be "released" independently once approved.
Does that mean the GlassFish build is using the "staging" profile
for its build, so it can pick up staged versions of its
dependencies?
We could choose to do it that way.
However, let me highlight that staging repositories can be dropped.
This is convenient as this may allow one to fix issues and "re-do" the release workflow for the very same version and thus avoid pushing "bad" artifacts to Maven Central.
While convenient, a "re-release" does NOT play nice with Maven as Maven caches non SNAPSHOT versions in the local repository permanently.
Re-releasing a given artifact that was pulled by various builds is tricky and requires invalidating cache.
Also it can be challenging to release GF to Maven Central in such case, as we need to make sure that all "staged" dependencies are released as well.
On
maven.java.net the nexus workflow allows to "promote" a staging repository, which locks the underlying staging repository (can't drop unless you drop the promoted one first).
The GF build was configured by default to pull from the promoted repository group.
People had direct access to
maven.java.net (via kenai role mapping) meaning they could drop a staging repository by mistake.
I guess this is why I've always thought of pulling from staging repositories as a thread to the build stability.
In eclipse the nexus account is only available from CI, maybe that makes it "OK" to consume from staging repositories ?
So when do I use the "snapshots" profile?
I guess I don't need to use it when deploying a snapshot,
correct?
I only need to use it if I want to make use of a SNAPSHOT release of
something else when building my project?
Yes.
Also, how is the Eclipse Maven repository used?
Is it just used as a cache of items from the release, staging, and
snapshot repositories?
It does have "hosted" repositories that can be pushed to directly, and one proxy repository of Maven Central that can be used for mirroring Maven Central.
If we decide to use the staging repository group actively, I'm sure we can ask the eclipse infra to setup a proxy repository for it.
We could also ask for a virtual repository to simplify mirroring (an aggregated repository used exclusively for mirroring).
Is nothing ever pushed directly to the
Eclipse Maven repository?
I found a group called "release", which I'd guess aggregates all the single -release hosted repositories.
