July 2025 - wildfly-dev - Jboss List Archives

Possible component upgrades report - wildfly-elytron:2.x

by thofman＠redhat.com

2 months, 2 weeks

1
0
0 / 0

Possible component upgrades report - wildfly-core:main

by thofman＠redhat.com

2 months, 2 weeks

1
0
0 / 0

Possible component upgrades report - wildfly:main

by thofman＠redhat.com

2 months, 2 weeks

1
0
0 / 0

Pull requests for WildFly 37 Final Due Wed July 9

by Brian Stansberry

FYI this is just a quick reminder that changes targeting WildFly 37 Beta pull requests are due a week from today, Wednesday, July 9. If there is anything you are trying to get in for WildFly 37 please feel free to reply to this message or ping me directly to let me know. The zulip release coordination thread for 37 Final is at #releases > WildFly 37 Final release <https://wildfly.zulipchat.com/#narrow/channel/424923-releases/topic/WildF...> . Best regards, -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His

2 months, 3 weeks

1
1
0 / 0

Possible component upgrades report - wildfly-elytron:1.x

by thofman＠redhat.com

2 months, 3 weeks

1
0
0 / 0

Possible component upgrades report - elytron-web:4.x

by thofman＠redhat.com

2 months, 3 weeks

1
0
0 / 0

Possible component upgrades report - wildfly-elytron:2.x

by thofman＠redhat.com

2 months, 3 weeks

1
0
0 / 0

Possible component upgrades report - wildfly-core:main

by thofman＠redhat.com

2 months, 3 weeks

1
0
0 / 0

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 months, 3 weeks

2
1
0 / 0

Possible component upgrades report - wildfly:main

by thofman＠redhat.com

2 months, 3 weeks

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev July 2025