On Thu, Jul 24, 2025 at 1:03 PM Brian Stansberry <bstansbe(a)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_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>
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