On Thu, Jul 24, 2025 at 1:03 PM Brian Stansberry <bstansbe@redhat.com> wrote:
Some more details on this.

Following are some of the factors affecting things. They are why I requested that people discuss things on zulip before deploying.

tl;dr; there are various risks and tradeoffs and people likely don't have all the info, so discuss before doing.

1) The mechanism to sync artifacts deployed to JBoss Nexus to Maven Central is not operating. The plan is that things that get deployed now to the non-staging repos will get synced later on when this is enabled, but this is risky.

2) When the sync mechanism is enabled it will be different from what was used in the past and will result in Maven requirements being enforced that were not enforced in the past. JBoss Nexus has some validation scripting that AIUI will mirror the Maven Central validation, but this is not enabled for staging repos. I requested this for two repos under https://issues.redhat.com/browse/NEXUS-950. If you are aware of other staging repos to include, please comment here AND on the JIRA.

Not validating in the staging repo introduces a risk that something that will fail validation would get promoted to one of our regular repos.

3) We've observed that the contents of at least one non-staging repo don't end up being publicly visible via the https://repository.jboss.org/nexus/content/groups/public/ URL that we tell users to use for reading. I don't think this affects projects whose code is in the 'wildfly' and 'wildfly-extras' orgs, but it affects other components used in WildFly, so I'm mentioning it here. 

4) People may not know what repo to CORRECTLY publish artifacts to. This is my fault for not socializing this before. I'll do that in a follow-up post in a bit. Bottom line: Don't assume you know because "of course code in GH location X must deploy to repo Y".

5) I drafted a document people could use to make sure their project was properly set up. It hadn't been vetted. It's here:

https://docs.google.com/document/d/1-6_vmFWzRVuMRwSuv_nOgG530qSDe6Ipc_eCERv6lrE/edit?tab=t.0

It's still a draft. The workflow it describes worked fine for a deployment-transformer-feature-pack:2.0.1.Alpha1 release to the wildfly-extras-staging->wildfly-extras repos. I want to verify it works for releasing for wildfly-staging->releases. I'll make another attempt at that in a bit.

It's no longer a draft. I successfully did a staging-deploy of org.jboss.wildscribe:*:3.1.1.Beta1 to wildfly-staging and a staging-move to releases. It worked, e.g.


Note: I chose this project because I don't think anyone will care or even notice if this beta never ends up in Maven Central. It's a tool used by WildFly to generate docs like https://docs.wildfly.org/36/wildscribe/.)

There are still other, more important, reasons listed here to have a discussion before deploying. So please continue to do that.


6) What's in that doc is much more complicated than ideal, because it spells out how to add pom content that we plan to provide in jboss-parent 50. But....

7) We're still tweaking what should go into jboss-parent 50.

8) There is a jboss-parent 50.alpha that should work. But due to #3 above it is not visible for ordinary reads from Nexus, so in practice it is not usable.

Best regards,
Brian

On Wed, Jul 23, 2025 at 10:58 AM Brian Stansberry <bstansbe@redhat.com> wrote:
As many of you know, JBoss Nexus is transitioning from Nexus 2 to Nexus 3 and as part of that the processes for how we deploy artifacts to it is changing significantly.

Please *do not deploy* anything from a project hosted in the 'wildfly' or 'wildfly-extras' GitHub orgs without discussing it with me first in a public thread in Zulip. Thanks!

I've long had a task to write and socialize instructions around how to do things in the new setup and I've actually made progress on that. Some of you have seen drafts etc.

But things are still in flux and we have a number of open questions about how things work or potential problems with the setup. So, please don't deploy things without discussion so we can be sure whatever you are planning will likely work.

Best regards,

--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His


--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His


--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His