Fully Enable BIRT's Support for PGP Signing

Summary

Please create a repository for birt in

https://repo.eclipse.org/content/repositories/

---

I'm not sure the current state of BIRT publishing to Maven Central.

I see the ci instances has this

Is that up-to-date?

I don't know if we need a GPG passphrase or if that's configured properly.

I don't know if settings.xml is configured for repository with id ossrh.

(I was comparing these to what's configured for EMF.)

Priority

• Urgent
• High
• Medium
• Low

Severity

• Blocker
• Major
• Normal
• Low

Impact

I'd like to fully test that https://ci.eclipse.org/birt/job/maven-publish/ can publish.

added IT-prioritylow IT-severitylow service:ossrh service:repo.eclipse.org team:releng labels

assigned to @fgurr

This issue contains two issues:

• deployment to repo.eclipse.org
• deployment to OSSRH/Central Portal

Deployment to OSSRH/Central Portal does not require deployment to repo.eclipse.org. Is there a good reason to set up a repo for BIRT on repo.eclipse.org?

This will allow snapshot versions to be published for testing and earlier feedback from consumers.

Maven Central Portal also supports snapshots. Isn't that sufficient?

I didn't expect to get push back. Is it generally preferred that projects not use repo.eclipse.org at all unless there is a sufficiently strong justification? What would be reasonable justification for the use of repo.eclipse.org? I'm just trying to understand what the reason for pushing back. I imagine we don't want to put too much load on this important server...

This is not a pushback, but rather an attempt to find the best approach, depending on the requirements. The goal seems to be to push official BIRT releases to Maven Central. Snapshot releases are supported there as well. That's why I'd like to find out if the extra build configuration that is required when repo.eclipse.org is used, plus the potential confusion that might be caused, is justified. Simple as that.

We will happily create a new repo for you on repo.eclipse.org if you like.

Actually I don't (BIRT doesn't) actually have a compelling need for repo.eclipse.org. Also, I was not aware that one could host snapshots elsewhere too. So let's forget about that for the time being because I really didn't plan to make significant use of that in the first place. If I can test the end-to-end publishing process in other ways (sooner rather than latter), ways that more fully test that the poms are conforming and all those constraints with signatures and such, that would be more than sufficient.

Ideally I would be able to test that I am able to publish a BIRT release via OSSHR before that becomes disabled, i.e., mid JUne. I'm not sure what's all in place for BIRT's ci instance already and what needs to be put in place for that to work.

(I was able to test the new process fully for EMF so I'm hopeful with the right sprinkling of magic spices it will all work smoothly. Note that EMF will publish very soon, before the end of the month, and at the point I'll be in a good position to be a guinea pig for migrating to the new central service.)

Thanks for your help and your advice...

BTW, I will only be publishing a very small subset of BIRT, the core runtime.

changed title from {-Create birt repository in https://repo.eclipse.org/content/repositories/-} to Fully Enable BIRT's Support for PGP Signing

marked the checklist item Medium as completed

marked the checklist item Low as incomplete

marked the checklist item Normal as completed

marked the checklist item Low as incomplete

mentioned in issue #5854

@fgurr

I really would like to make progress now that BIRT is released. What's needed here to move forward?

Actually I think it's enabled properly because this worked:

• https://ci.eclipse.org/birt/job/maven-publish/8/console

And produces the *.asc files:

• https://ci.eclipse.org/birt/job/maven-publish/lastBuild/artifact/repo-signed/org/eclipse/birt/org.eclipse.birt.axis.overlay/4.20.0/

There were some warnings like this, but I guess that's okay or should we do something about that?

09:52:57  [WARNING] 
09:52:57  [WARNING] Do not store passphrase in any file (disk or SCM repository),
09:52:57  [WARNING] instead rely on GnuPG agent or provide passphrase in 
09:52:57  [WARNING] MAVEN_GPG_PASSPHRASE environment variable for batch mode.
09:52:57  [WARNING] 
09:52:57  [WARNING] Sensitive content loaded from settings.xml
09:52:57  [WARNING] 

I think the only thing I still need to to have access to org.eclipse.birt namespace via my account merks at https://central.sonatype.com which currently just has org.eclipse.emf:

---

I did a trial run for EMF publishing and that was successful:

So I think we're in good shape thanks to the IT team's help with the migration.

marked this issue as related to #5854

@heurtemattes

What's the outlook on updating my central account?

As a committer of BIRT and not a project lead, this doesn't scale for us. We can't manage all committers for all namespace.

The new central portal UI doesn't yet allow adding users to a namespace, so we need to contact Sonatype support.

In any case, even if you have access to the namespace, there are limitations reported by Sonatype support that I still need to verify. Currently there is a limitation that deployments can ONLY be viewed by the user that uploaded the deployment. There is a feature in the works that will allow ANY (verified) user to see and release a deployment, but that has been delayed due to the ongoing migration.

The recommended way by sonatype for now is using the deployment API. https://central.sonatype.org/publish/publish-portal-api/#publish-or-drop-the-deployment

I'm not entirely sure what you are telling me. It's definitely the case that @wjongman is expecting me to be able to do this task as part of the release engineering work that I do for the BIRT team:

https://github.com/eclipse-birt/birt/issues/625#issuecomment-2975288509

I already have the BIRT upload prepared and, as I mentioned, I was able to upload such a result successfully for EMF. It may well be the case that as the person who uploaded it I'm the only one who can see the deployment, but that's not currently a problem or a concern.

In any case, @hwellmannwr6 drew my attention to https://central.sonatype.org/publish/publish-portal-api/ already but we're not sure how to use that API, e.g., from where can we get the tokens without breaching their security? We plan to explore this for better automation in the future.

But BIRT has just released 4.20 so for right now I only need access/permission for the namespace so that I can publish it to Maven Central.

Are you saying that contacting Sonatype support to provide me access to the namespace is something you cannot do, or is something for which you won't have time for x number of days?

I have just sent an email to sonatype.

Thanks, Sébastien!

I just followed up with support regarding this request.

@emerks You've been added to the birt namespace.

That's great, thanks!!

Yeah! I successfully published the 4.20.0 release, e.g.,

https://repo.maven.apache.org/maven2/org/eclipse/birt/org.eclipse.birt.core/4.20.0/

Thank you for your support.

assigned to @heurtemattes

added statewip label

mentioned in issue #5913 (closed)

mentioned in issue #6328 (closed)

closed

removed statewip label

mentioned in issue #6361

mentioned in issue #6130 (closed)