(Add a link to or paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)
Priority
Urgent
High
Medium
Low
Severity
Blocker
Major
Normal
Low
Impact
Luckily, we should be done with Jakarta EE 11 by then (fingers crossed). The new solution must be running fairly quickly to avoid disruption in the development of Jakarta EE 12.
The technology.lyo project would need assistance with this too, please. Our current releng depends on Jenkins (#6115 (closed)). If the releng team would kindly provide a supported path to migrate from OSSRH+Jenkins to the new Portal + GH Actions, we would do our best to adopt.
The first batch of migrations will happen on June 9, which is two days before the Eclipse IDE 2025-06 GA. So all projects should have published their Maven bits by then.
If, for some reason, this does not align with schedules, projects can opt out of the June 9 date and postpone it to June 24.
As far as I can tell, at least for the Eclipse-TLPs, the deployment to Maven-Centrals happens only very short before the release date.
So it will probably exactly around that day.
Therefore I suggest that all Eclipse-TLPs should request to be postponed to June 24th, but lets discuss that in #6130.
Should I create a standalone issue for GlassFish projects? I see in the spreadsheet that the automatic migration failed and you need help from Sonatype, so for the GlassFish team would be worth to monitor the progress at least, perhaps also to help with the migration if needed.
Yes, please go ahead. GlassFish is heavily impacted by the migration, and it would be worthwhile to create a dedicated issue to address different aspects of the migration.
Note: A support request was sent last week, on Wednesday, May 21st, regarding accounts with missing namespaces in Central. This affects all the listed projects.
We have not yet received a response from sonatype support.
Thanks for all you do with this and other Eclipse IT aspects.
For the Jakarta EE Platform project and Platform TCK project, we request that we do not include these projects in the June 9th wave. The reason for this request: we will be doing ballots for Jakarta EE 11 at that time.
Instead, we want these projects to be in the next wave.
Could you please confirm whether the following project_id are related to your request?
ee4j.jakartaee-platform
ee4j.jakartaee-tck
Should I also include: ee4j.jakartaee-stable?
Additionally, I’ve noticed that several other projects use the jakarta.* namespace, such as ee4j.cdi, ee4j.ca, ee4j.cu, ee4j.el, and others.
Should these be included in the request as well?
All Jakarta Specification projects use the jakarta.* namespace, but these can all go in the June 9 batch.
The Platform and TCK, as mentioned above, have staged artifacts in the jakarta.oss.sonatype.org staging repository that are going to be released to Maven Central between June 9 and June 24. That is why we want to hold off on these two exclusively.
If username and password are aready available we can create it in the pipeline on the fly.
If it's not yet available, it would be ideal if you could add the final Bearer token as credential to the releng JIPP, for releng (that's the alias for org.eclipse.platform), jdt and pde.
And if you add these tokens, it would be even better if you could use platform instead of releng as project name in the id.
I have already tried to read username and password from the existing settings-deploy-ossrh-releng/pde/jdt.xml files, but that didn't work and I think it's also not ideal to require a lot of handling of credentials.
This configuration is required only for projects that rely on the staging feature, which is not the case for most of them.
The settings.xml file has already been updated with the new credentials across all Jenkins instances.
For now, we have chosen to apply this manually, as we expect improved integration of the staging feature in the Maven plugin in the future.
secrets have been added to releng, jdt and pde instances as central-sonatype-bearer-tokenname.
Thank you for your help. But that is only partially what I what we need. We need these bearer tokens for the releng, jdt and pde namespace available within the RelEng JIPP.
And it would be ideal, if you could use platform as prefix or suffix for the releng token.
So that we eventually have in the releng JIPP the credentials named something like
central-sonatype-bearer-tokenname-platform for the releng namespace (which is eventually o.e.platform again)
central-sonatype-bearer-tokenname-jdt for the JDT namespace
central-sonatype-bearer-tokenname-pde for the PDE namespace
But with the already present token for releng I was able to test the adjustments of the pipeline and created a draft PR for it at:
I just noticed that when proposing the names, I made a copy-paste mistake and I think the name element in central-sonatype-bearer-tokenname-X is actually unnecessary and could be misleading.
It would be nice to have (technically everything works fine), if you could change it to central-sonatype-bearer-token-X. OTOH, in case you roll out the new variable en masse, we can also just await and use the schema you use for that.
If I understand correctly those secrets are also needed on each Jenkins instance. Will those be added to the instances "automatically"? E.g., I don't think BIRT has everything it needs in that regard: