The settings.xml we use is injected by the Jenkins setup for out
jobs. If changing the settings.xml could make this transparent,
that would help, but it appears that hasn't been done.
Unfortunately, that would also mean that builds outside of the
Jenkins infrastructure would need to modify the settings.xml, which
seems like a recipe for failure. It's hard enough to get people to
build using a profile instead of just "mvn". Getting them to modify
their settings.xml, or use a different settings.xml, doesn't seem
likely to happen.
Putting the configuration in the parent pom and requiring people to
build using a profile defined there seemed like the best we could
do. If there's a way to modify the configuration in the parent pom
so that the build would work
without using a profile, that
would be even better, but I'm not enough of a Maven expert to know
how or if we could do that.
Terry Yanko wrote on 1/22/20 8:33 AM:
Hi Bill,
I got some feedback from my college Joel Orlina related to
the issue above (he did most of the provisioning for
jakarta.oss.sonatype). Here is what he had to say:
Typically, the server ID that the
build uses is sourced in a Maven settings.xml file. And I
would have figured that their build processes sourced the
settings.xml file from a Central location. I can't recall
off the top of my head whether you can specify a different
settings file in a profile, but maybe that's what's
happening.
Is this helpful at all?
Best,
Terry
The console output is
here.
You can see that without the use of the -Pstaging profile
it's trying to access
oss.sonatype.org
instead of
jakarta.oss.sonatype.org.
Is there supposed to be something that redirects it to
jakarta.oss.sonatype.org?
Without that, I completely understand why it's failing.
How do you think this is supposed to work?
Terry Yanko wrote on 1/20/20 9:16 AM:
Hi Bill,
There should have been no additional configuration
options required to release against the
jakarta.oss.sonatype.org
endpoint. I'm glad you found a partial workaround, but
if you could please provide logs from the initial
failed deployment we can help diagnose the issue.
Also, consider creating a new ticket for this at
https://issues.sonatype.org/projects/MVNCENTRAL which
would raise the visibility of this issue to our other
team members.
Best,
Terry
I thought that all
I would need to do to use the new Nexus was to change
my
project to use the new parent pom with the new profile
configurations and then
poof! it would all work just like before.
That appears to not be the case.
Previously I could deploy to the staging repository
without specifying any
special profile; the default deployed to the OSSRH
staging repository. But now
I want to deploy to the Jakarta Nexus staging
repository, so all deployment
operations need to specify "-Pstaging" to get the
configuration for the new
repository. And of course that means I can only
deploy projects that have been
updated to use the new parent pom. (There's probably
a way to deploy an older
project without updating it, but I'll let someone else
figure that out.)
I figured this out the hard way. I sure wish someone
had written this down.
What are the other changes I'm going to need to make?
In particular, how
exactly should I release staged artifacts and promote
them to final? Do I just
use -Pstaging along with nexus-staging:rc-release?
