Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Migration to Jakarta installation of Nexus

There is no change to do in the settings.xml file. It only contains credentials for repositories with the id "ossrh":

<settings>
  <servers>
    <server>
      <id>ossrh</id>
      <username>jaf-bot</username>
      <password>*********</password>
    </server>
  </servers>
</settings>

 As the changes for v1.6 of the parent pom (https://github.com/eclipse-ee4j/ee4j/compare/4f61cce..master#diff-04dc5d029560773ac79faaf3da0fbb22) only updates the URL and not the repositories ID (it's still "ossrh"), then maven will use the same credentials.

Could it be that you actually never deploy to staging with this commit before https://github.com/eclipse-ee4j/jaf/commit/0345740ecc36698e11a22bea7f86a3ec4c85e0a2#diff-600376dffeb79835ede4a0b285078036? Maybe without this one, you'll be able to get your old behavior back.

HTH.

Mikaël Barbero 
Team Lead - Release Engineering | Eclipse Foundation
🐦 @mikbarbero
Eclipse Foundation: The Platform for Open Innovation and Collaboration

Le 22 janv. 2020 à 18:59, Bill Shannon <bill.shannon@xxxxxxxxxx> a écrit :

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.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 

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 change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc

Attachment: signature.asc
Description: Message signed with OpenPGP


Back to the top