[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-pmc] Migration to Jakarta installation of Nexus
|
Thank you, Terry,
for all of the help you provided during our transition to the new repo!
Best of luck with your new endeavors!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Terry
Yanko <tyanko@xxxxxxxxxxxx>To:
Bill
Shannon <bill.shannon@xxxxxxxxxx>Cc:
EE4J
PMC Discussions <ee4j-pmc@xxxxxxxxxxx>, Joel Orlina <jorlina@xxxxxxxxxxxx>Date:
03/13/2020
12:26Subject:
[EXTERNAL]
Re: [ee4j-pmc] Migration to Jakarta installation of NexusSent
by: ee4j-pmc-bounces@xxxxxxxxxxx
Hi All, Today will be my last day at Sonatype.
It's been a pleasure to work with this group related to the migration and
I hope the service continues to serve you well! For any questions related
to the management of jakarta.oss.sonatype.orgfrom here on out, please contact Joel Orlina directly and he should be
able to assist you. For standard technical support questions, as was previously
noted, simply create a ticket at https://issues.sonatype.org/projects/MVNCENTRAL and
a member of the Central team will be able to assist you. Thanks and have a great weekend!Terry On Wed, Jan 22, 2020 at 1:08 PM Bill
Shannon <bill.shannon@xxxxxxxxxx>
wrote: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 On Mon, Jan 20, 2020 at 3:59 PM Bill
Shannon <bill.shannon@xxxxxxxxxx>
wrote:The console output is here.
You can see that without the use of the -Pstaging profile it's trying to
access oss.sonatype.orginstead 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.orgendpoint. 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 On Fri, Jan 17, 2020 at 8:06 PM Bill
Shannon <bill.shannon@xxxxxxxxxx>
wrote: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?
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc