Use of the 'org.wildfly' groupId
by Brian Stansberry
Currently we have a number of different repos publishing artifacts using
the 'org.wildfly' groupId with no further namespacing.
Going forward I don't think we should allow any other new repos to do that.
It leads to administrative hassles, e.g. with setting things up in Nexus.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 month, 2 weeks
WildFly 39 schedule
by Brian Stansberry
Following are my proposed dates for work on WildFly 39:
39 Beta
PRs due: Wed Dec 3
Tag and deploy: Wed Dec 10
Release: Thu Dec 11
39 Final
PRs due: Wed Jan 7
Tag and deploy: Wed Jan 14
Release: Thu Jan 15
As usual for our January release we'll have a longer period between
the Beta and Final to account for lots of people being unavailable
late in December.
These are the dates currently in https://www.wildfly.org/events/#calendar.
If you are one of the folks responsible for one of the release
deliverables and these dates are problematic, please let Darran
Lofhouse or me know.
The Zulip thread for release coordination discussions for the beta is
at https://wildfly.zulipchat.com/#narrow/channel/424923-releases/topic/WildF...
Best regards,
Brian Stansberry
WildFly project lead
He/him/his
4 months
WildFly JUnit Extension and Tooling
by James Perkins
Hello All,
In some free time, I created a new project for WildFly i'm calling
wildfly-testing-tools [1]. Currently this includes a JUnit Extension for
managing a WildFly instance for tests. Please note this is NOT a
replacement for Arquillian. This is aimed for cases that are much more
simple than what Arquillian can handle.
This could end up being used in WildFly Core as a replacement for the JUnit
4 TestRunner we have. The idea for this project came from me wanting to
migrate the wildfly-maven-plugin to use JUnit 6. I needed a replacement for
a simple test runner that is similar to what we have in WildFly Core, so I
created this :)
I also moved some things from WildFly Arquillian into this project. The
reason being these were useful testing tools, but really don't have
anything to do with Arquillian. These extensions can be used with or
without Arquillian.
I'd like to propose we make this a WildFly project. I'd like others to have
a look and let me know if they would find it useful. I don't think it's
something we want to bring into WildFly testing itself, but I can see it
being useful for WildFly Core or projects where Arquillian might be a bit
of an overkill.
[1]: https://github.com/jamezp/wildfly-testing-tools
James R. Perkins
Principal Software Engineer
4 months, 2 weeks
Moving WildFly Elytron to Java 17
by Darran Lofthouse
Now that WildFly Core is built for Java 17 I would like to move WildFly
Elytron to Java 17 as well from our next releases for WildFly (2.7.x +).
Would this cause any issues for other projects that depend on WildFly
Elytron?
It should not affect Undertow as we use the Elytron Web project for
integration, maybe JBoss Remoting but also others with an Elytron
dependency so let me know if this would be an issue for your project.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
4 months, 2 weeks
Initial list of WildFly AS Maintainers
by Brian Stansberry
The GOVERNANCE.md for WildFly AS that we adopted last week includes a
"Maintainer" role. Alongside that GOVERNANCE.md we have a Team.md
where we'll list the people in the various roles. We need to populate
that document.
I've sent up https://github.com/wildfly/wildfly-governance/pull/7 to
do that for the Maintainer role, plus a subset of those in the
'Publisher' role -- those who publish the main wildfly/wildfly repo.
Your inputs on this are most welcome!
The GOVERNANCE.md defines Maintainers as:
"Contributors eligible for write access to a code repository for a
WildFly Application Server project. Responsible for driving
initiatives and reviewing/merging contributions in their area of
expertise. Write access might be limited to particular repositories."
So I started from the premise that our initial maintainers are those
who we've given write perms in the past. I did some tool-drive Github
inspection + discussion with various folks who deal with GH orgs where
my tool didn't work, plus some permission list cleanup discussions.
The resulting set of names is in the PR.
Thank you to those of you who helped me with this!
Going forward, before any grants write access to any of the dozens of
WF AS repos we should check that they are on the Maintainer list and
if not have a discussion to get them added.
Best regards,
Brian Stansberry
WildFly project lead
He/him/his
5 months
