Romain Grécourt wrote on 10/19/2018 07:10 PM:
Romain Grécourt wrote on
10/18/18 04:26 PM:
>
>
> 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.
But currently we are not?
Then how are we incorporating newer versions of components into
GlassFish? Are we only doing so for those components that have
passed an Eclipse release review and have been published?
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.
I assume it's relatively rare that we need to drop a staging
repository and re-release a component. Since the current build jobs
seem to start with an empty Maven local repository, invalidating the
cache wouldn't be an issue, right?
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 ?
I assume all the external projects integrating with GlassFish would
need to manage their use of the staging repository and close and
release it at the appropriate time.
With JavaMail, for example, I wanted to make sure a new version of
JavaMail worked in GlassFish before declaring it a final release.
Usually I did this by releasing an "rc1" version, integrating that
with GlassFish, running all the GlassFish tests, and if they pass I
would release the final version and integrate that with GlassFish.
Assuming the only change between the rc1 version and the final
version was the version number, that seemed relatively safe.
By using the staging repository, I could release the final version
to the staging repository, integrate that into GlassFish, run the
GlassFish tests, and if they all pass I could submit the Eclipse
release review and when it is approved I could release the final
version from the staging repository.
Isn't that what we should encourage external projects to do when
integrating with Eclipse GlassFish?
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.
When deploying a SNAPSHOT release that I want to make available to
the public, do I use the "oss-release" profile, or no profile at
all? And which Maven repository does it end up in?
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.
I'm not clear on the implications of all that. Should we ask
Eclipse to change something about their Nexus instance? Or should
we just use it the way it's set up today? If something needs to be
changed, can you submit the request, and then explain to the rest of
us what we should change in our use of Maven to make use of the
change to Eclipse Nexus?
|
