Migrating Testsuite Maven Modules to JUnit 5
by James Perkins
As a general topic, this is something I've been looking at for a while.
I've submitted the first migration [1] for the smoke tests. Please note
that if you've got an open PR that touches the smoke tests, you will likely
need to update it.
For the future, I would like to slowly migrate Maven modules (subprojects)
as well. This will not be a fast moving migration nor is there anything
component leads need to specifically do with this migration. However, if
you're interested in helping please reach out to me. We want to be very
careful with what we change and when we change it. We really need to make
sure we coordinate every change.
Why should we do this? In general JUnit 5 is the path forward for JUnit
testing. While JUnit 4 still works, there could be a point where it won't
work on newer versions of Java. I suspect changes will not be made to JUnit
4o to fix that.
In my opinion, this is a good step forward and JUnit 5 is a much more
pleasant experience with modern Java. Some very small examples of what can
be done can be seen in the, probably poorly named, WildFly Arquillian JUnit
API [2[.
[1]: https://github.com/wildfly/wildfly/pull/19032
[2]: https://github.com/wildfly/wildfly-arquillian/tree/main/junit-api
James R. Perkins
Principal Software Engineer
Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>
2 weeks
Request for a feature team - client and server handler versioning for Wildfly HTTP client
by Richard Achmatowicz
Hello
The Wildfly Client libraries (EJB client, Naming client and Transaction
client) are used to allow applications to remotely access deployments on
Wildfly server instances. The EJB client, Naming client and Transaction
client libraries include support these activities over a JBoss Remoting
transport protocol. The Wildfly HTTP client library adds in support for
these activities over the HTTP protocol. The changes described below
apply to the Wildfly HTTP client.
In order to add new features to the Wildfly HTTP client, we require the
ability to version client-side and server-side request and response
handlers, as the use of clients and servers from different Wildfly
versions is supported (see EAP interoperability
<https://access.redhat.com/solutions/6985239>). Additionally, in order
to allow clients and servers of differing versions to interoperate, we
require a handshake protocol to establish an agreed version of the
client and server side handlers to use during their interactions.
This scope of this issue is to implement a client-side and server-side
handler mechanism and to adjust the existing handshake protocol (EE
interoperability handshake).
For more information on this issue:, as well as the relevant process
issues see the analysis document
<https://github.com/wildfly/wildfly-proposals/pull/742>.
We have the key players for a feature team for a "community" stability
level feature team on hand (component lead, developer, SMEs), but if you
are interested in this topic please don't hesitate to get involved. We
always welcome additional perspectives and contributions!
Richard
2 weeks, 2 days
Governance process for WildFly projects
by Brian Stansberry
Now that we've moved to Commonhaus, we need to adapt a new governance
document for WildFly. So let's discuss!
I've created a google doc at [1] to help facilitate discussion. Anyone can
comment on that doc or suggest edits. We can use doc comments to discuss
and we can discuss in this thread. Let's try and do any really deep
discussions here.
A challenging aspect of this kind of thing is the scope of WildFly. A
number of significant projects that provide components to the WildFly AS
but which have their own distinct branding, community, usage etc
independent of their use in the AS moved to Commonhaus sponsorship as part
of WildFly:
* Ironjacamar
* JBeret
* JBoss Parent
* JBoss Threads
* JBoss WS
* Narayana
* RESTEasy
* Undertow
* Weld
I committed to the leads of those projects that they'd be able to define
their own project governance, so long as it was compatible with Commonhaus
requirements. But, we do need some form of top level document, if for
nothing else to define the role of the person who represents everyone on
the Commonhaus Extended Governance Committee.
So, in the google doc I created a document for the overall "WildFly
Commonhaus Organization" that's focused on that bit and spells out the
concept of "Top Level Projects", listing the ones above along with the
"WildFly Application Server" project.
And then I created a separate document for the "WildFly Application Server"
project. The other projects listed above would create their own such
document that suits their requirements. (The google doc also includes a
kind of template for such a thing.)
I blatantly ripped off a lot of text in the google doc from Hibernate's
GOVERNANCE.md[2] Hibernate has a degree of similarity to the "WIldFly
Commonhaus Organization" in that there are distinct Hibernate projects
(ORM, Search, Validator, etc) that are cooperatively developed.
What I've written is deliberately very light on rules about decisions are
made, emphasizing cooperation and consensus. Partly that's was to keep this
first draft as simple as possible. And partly it's because maybe that's
best.
Note that I'd like to get something in place in the next month or so, in
order to meet a Commonhaus onboarding requirement. But for sure what we
come up with is not fixed in stone; if we have ideas we want to explore we
can definitely iterate. I'd like to get the "WildFly Commonhaus
Organization" part pretty nailed down quickly, but it's pretty simple. It's
the "WildFly Application Server" top level project that is more substantive.
Best regards,
Brian
[1]
https://docs.google.com/document/d/1r2i17R6VtqGeslKlyH6lWVIQix0-QCiMa_6na...
[2] https://hibernate.org/community/governance
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 weeks, 5 days
