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

This is one of two follow-up posts regarding item #4 from my last post. This one is for projects that ARE ALLOWED to deploy to the wildfly-extras-staging repo for promotion to the wildfly-extras repo. ONLY projects that produce artifacts whose groupIds match one of the following are allowed to deploy to wildfly-extras-staging and wildfly-extras. org.cajun.navy org.wildfly.deployment:* org.wildfly.examples, org.jboss.qa.appsint org.wildfly.extras:adoc-maven-plugin-descriptor org.wildfly.extras.batavia:* org.wildfly.extras.creaper:* org.wildfly.extras.graphql:* org.wildfly.extras.grpc:* org.wildfly.extras.reactive:* org.wildfly.extras.sunstone:* org.wildfly.extras.vertx:* org.wildfly.llm:* org.wildfly.generative-ai:* If you think there should be something else on that list, wait a bit for my next post. A number of projects in the 'wildfly-extras' GitHub org should be 'promoted' to the 'wildfly' org, and in anticipation of that their artifacts will be listed on the next document. If something doesn't show up there either, please let me know via a reply here or in public zulip. On Thu, Jul 24, 2025 at 1:03 PM Brian Stansberry <bstansbe(a)redhat.com&gt; 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_eCE... > > 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. > > 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(a)redhat.com&gt; > 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

On Thu, Jul 24, 2025 at 1:03 PM Brian Stansberry <bstansbe(a)redhat.com&gt; 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_eCE... > > 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. https://repository.jboss.org/nexus/service/rest/repository/browse/public/... 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(a)redhat.com&gt; > 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

Good news. :-) Things seem to be smoothed out and a number of things have been deployed to JBoss Nexus and successfully synced to Maven Central. Most important of those is JBoss Parent 50 is now available there, which means you can use it as the parent for your project and take advantage of all the work that went into simplifying deploying to the updated JBoss Nexus. For WildFly projects https://docs.google.com/document/d/1-6_vmFWzRVuMRwSuv_nOgG530qSDe6Ipc_eCE... spells out some best practices for how to set this up. Please read that thoroughly before deploying, particularly the bit about using JBoss Nexus tasks to validate your staged content. I recommend continuing to discuss in Zulip first before deploying -- ask questions etc, at least for your first release under this new setup. Note that David Hladky has also socialized https://github.com/dhladky/wildflyextras/blob/master/nxrmplugin/pom.xml as an example to learn from. Please note that despite the name it IS NOT a prescription for how to deploy WildFly Extras projects; it's more of a generic instruction using wildfly-extras as an example. In particular dhladky/wildflyextras does not use jboss-parent as the parent, while most, maybe all Wildly projects do. Please refer to the Google doc linked above and follow what it says when possible. That said, dhladky/wildflyextras is a great resource for learning details of this. In particular it is likely to be helpful for projects that can't upgrade to JBoss Parent 50 and need to configure some of what 50 does in their own pom. Make sure you know what repository to use for staging and what repository to use as the ultimate home for the artifacts. Don't assume; if you haven't been clearly told, then ask. A lot of you got private emails from sent July 24 describing the repos to use for a bunch of different groupId:artifactId patterns. Those are reliable instructions. They didn't cover everything though, just the subset of GAs where I personally help coordinate. There are other GA patterns that use different repos, and other people are responsible. So please ask. On Tue, Aug 5, 2025 at 2:04 PM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: > Status update: > > tl;dr; Please continue to discuss on zulip first before releasing > 'wildfly' projects. Things are still not completely smoothed out, so it's > best to discuss first, then do. > > NO ONE should directly deploy 'wildfly' artifacts directly to the > 'releases' or 'wildfly-extras' repos. (IMHO no one should directly deploy > other content to 'releases' either, but I have no authority related to work > on other projects.) You must deploy to wildfly-staging or > wildfly-extras-staging and validate your content before using > nxmr3:staging-move to move it to its final destination repo (e.g. > 'releases' or 'wildfly-extras'.). This is critical! Part of the workflow > that syncs content to Maven Central is a job that validates content in a > repo being synced for compliance with central's requirements. If it finds > non-compliant content, it stops. For everything, not just whatever > problematic artifact it finds! So, don't screw things up for everyone by > pushing invalid content! Push to a staging repo and make sure it's valid > before doing a staging-move. > > I'll describe the details of how to 'make sure it's valid' privately with > those with perms to deploy to wildfly-staging and wildfly-extras-staging. > > The latest news: > > We released WildFly 37.0.0.Final yesterday using new workflows based on > the nxrm3-maven-plugin. The sync of that content to Maven Central is still > in progress. That part still isn't smooth, which is one reason to still be > cautious. > > Paul Ferraro has done good work on jboss-parent to make it simpler to do > a proper workflow. Perhaps tomorrow we'll release a beta or a final of > jboss-parent with those changes. Discussion at .#wildfly-developers > > JBoss Parent 50 @ 💬 > <https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t... > > Unless something is really urgent I suggest waiting for jboss-parent to > be released before releasing something. Use it instead of manually adding a > lot of config into your project that you'll later remove. > > On Thu, Jul 24, 2025 at 3:11 PM Brian Stansberry <bstansbe(a)redhat.com&gt; > wrote: > >> >> >> On Thu, Jul 24, 2025 at 1:03 PM Brian Stansberry <bstansbe(a)redhat.com&gt; >> 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_eCE... >>> >>> 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. >> >> >> https://repository.jboss.org/nexus/service/rest/repository/browse/public/... >> >> 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(a)redhat.com&gt; >>> 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 >> > > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His > -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His