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 _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

James R. Perkins Principal Software Engineer On Tue, Oct 28, 2025 at 6:37 AM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: > First, just a note: if this becomes the replacement for org.wildfly.core.testrunner.WildFlyRunner then > it would be used in the main WildFly code base. WildFlyRunner is used in > testsuite/manualmode. The server lifecycle in that testsuite is not meant > to span the surefire execution and is therefore controlled by the tests > themselves. So some tests used WildFlyRunner instead of Aquillian. > This is good to know. I thought we had a rule of not using it in the WildFly test suite, but that might be wishful thinking on my part :) I currently don't support manual mode, but that should be possible to implement. > > Second, re the other tools, with that you've kind of opened the topic of > wildfly-core-testsuite-shared, which is a somewhat messy mix of common > utilities useful in testing any any stack based on the WildFly Core kernel, > and then stuff that's just meant to be shared between various testsuite > modules in WildFly Core itself. The former part being heavily used in the > main WildFly testsuite. At a very quick glance, the tools stuff in your > repo looks like more of the former. So we should think about where we want > that kind thing to live. > Agreed. That makes sense to me. The intent of this tooling is as you assumed, tooling to be used for testing with a WildFly Core based server. I'd be happy to move more utilities over as well. I'm sure there are things other projects may find helpful. > > One factor in that kind of thinking is a distinction between the > wildfly-core-testsuite-shared stuff and probably what you have in mind for > your repo is that we generally say that the wildfly-core-testsuite-shared > stuff can only be used in wildfly/wildfly-core or wildfly/wildfly. So if we > changed something and that broke someone using it some other way, we'd not > fix that if it interfered with the main needs. I'd think that if we moved > something out of wildfly-core-testsuite-shared and into wildfly-testing-tools > we'd be saying it's more broadly usable and we'd maintain it that way. > Agreed which is why it's something I've left more generic, e.g. start/stop a server, deploy an application, execute CLI commands, etc. I hadn't planned on doing some kind of ServerSetupTask, but I guess that could make sense that we could add some kind of task to execute before deployments and after an undeploy. Something like that might make sense though as we might be able to share it with WildFly Arquillian which IIRC we did try to create some kind of a bridge at one point. > > On Mon, Oct 27, 2025 at 10:47 PM James Perkins via wildfly-dev < > wildfly-dev(a)lists.jboss.org&gt; wrote: > >> 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 >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >> > > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His >

Moving to wildfly-extras sounds ok. This seems like quite a lot and it's pretty new so the incubating nature gives a bit more freedom to break things you decide aren't right.

If this is going to surface in the feature set of wildfly-maven-plugin then you're already in a mode of "can't break that", so going straight to the 'widlfly' org would make more sense. But I think maybe you mean you are going to use this as part of the infrastructure to test wildfly-maven-plugin? That's an internal detail and using incubating stuff is fine.

Tangent: the minVersion thing for a module seems a bit underspecified, as modules don't have versions. The server that uses the module does, which is what I think you mean. (Note my understanding of this is 100% from the README; I didn't look at the code.)

On Mon, Nov 10, 2025 at 2:21 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > I've added support for manual mode tests > https://github.com/jamezp/wildfly-testing-tools?tab=readme-ov-file#manual.... > If things look okay, I'd like to move this to either the wildfly or > wildfly-extras organization as I'd like to start using it in the > wildfly-maven-plugin. If we don't think we want something like this, that > is okay too. I can just copy some things over to the wildfly-maven-plugin. > > > James R. Perkins > > Principal Software Engineer > > > On Tue, Oct 28, 2025 at 7:27 AM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> >> >> James R. Perkins >> >> Principal Software Engineer >> >> >> On Tue, Oct 28, 2025 at 6:37 AM Brian Stansberry <bstansbe(a)redhat.com&gt; >> wrote: >> >>> First, just a note: if this becomes the replacement for org.wildfly.core.testrunner.WildFlyRunner then >>> it would be used in the main WildFly code base. WildFlyRunner is used in >>> testsuite/manualmode. The server lifecycle in that testsuite is not meant >>> to span the surefire execution and is therefore controlled by the tests >>> themselves. So some tests used WildFlyRunner instead of Aquillian. >>> >> >> This is good to know. I thought we had a rule of not using it in the >> WildFly test suite, but that might be wishful thinking on my part :) I >> currently don't support manual mode, but that should be possible to >> implement. >> >> >>> >>> Second, re the other tools, with that you've kind of opened the topic >>> of wildfly-core-testsuite-shared, which is a somewhat messy mix of common >>> utilities useful in testing any any stack based on the WildFly Core kernel, >>> and then stuff that's just meant to be shared between various testsuite >>> modules in WildFly Core itself. The former part being heavily used in the >>> main WildFly testsuite. At a very quick glance, the tools stuff in your >>> repo looks like more of the former. So we should think about where we want >>> that kind thing to live. >>> >> >> Agreed. That makes sense to me. The intent of this tooling is as you >> assumed, tooling to be used for testing with a WildFly Core based server. >> I'd be happy to move more utilities over as well. I'm sure there are things >> other projects may find helpful. >> >> >>> >>> One factor in that kind of thinking is a distinction between the >>> wildfly-core-testsuite-shared stuff and probably what you have in mind for >>> your repo is that we generally say that the wildfly-core-testsuite-shared >>> stuff can only be used in wildfly/wildfly-core or wildfly/wildfly. So if we >>> changed something and that broke someone using it some other way, we'd not >>> fix that if it interfered with the main needs. I'd think that if we moved >>> something out of wildfly-core-testsuite-shared and into wildfly-testing-tools >>> we'd be saying it's more broadly usable and we'd maintain it that way. >>> >> >> Agreed which is why it's something I've left more generic, e.g. >> start/stop a server, deploy an application, execute CLI commands, etc. I >> hadn't planned on doing some kind of ServerSetupTask, but I guess that >> could make sense that we could add some kind of task to execute before >> deployments and after an undeploy. Something like that might make sense >> though as we might be able to share it with WildFly Arquillian which IIRC >> we did try to create some kind of a bridge at one point. >> >> >>> >>> On Mon, Oct 27, 2025 at 10:47 PM James Perkins via wildfly-dev < >>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>> >>>> 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 >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>> List Archives: >>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Architect, JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His

On Thu, Nov 13, 2025 at 2:02 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > James R. Perkins > > Principal Software Engineer > > > On Thu, Nov 13, 2025 at 9:36 AM Brian Stansberry <bstansbe(a)redhat.com&gt; > wrote: > >> Moving to wildfly-extras sounds ok. This seems like quite a lot and >> it's pretty new so the incubating nature gives a bit more freedom to break >> things you decide aren't right. >> > > That makes sense to me. > > >> >> If this is going to surface in the feature set of wildfly-maven-plugin >> then you're already in a mode of "can't break that", so going straight to >> the 'widlfly' org would make more sense. But I think maybe you mean you are >> going to use this as part of the infrastructure to test >> wildfly-maven-plugin? That's an internal detail and using incubating stuff >> is fine. >> > > Nothing will be exposed from the wildfly-maven-plugin, I just want to use > it for testing so I can start migrating tests to use JUnit 6. > > >> >> Tangent: the minVersion thing for a module seems a bit underspecified, >> as modules don't have versions. The server that uses the module does, which >> is what I think you mean. (Note my understanding of this is 100% from the >> README; I didn't look at the code.) >> > > I do need to do some work on the README now that it has grown. The idea > behind that is you can enable/disable a test based on the version defined > in an artifact/resource provisioned in the server. I can see where it can > be a bit confusing, but the idea is you write a test that only works on > newer versions of WildFly, but you want to also test with older versions. > Instead of having to specify a bunch of profiles to tags for each version, > you can simply use the minVersion to say "This test only works on WildFly > 38 and higher, please ignore it on lower versions". Given modules > themselves don't have versions, I suppose that can be confusing. However, > I've found it very useful in RESTEasy to resolve the version from the > artifact GAV or downloaded JAR. > Yeah, it makes sense; it's really just a matter of wording. And likely people will get the idea regardless. \

> >> >> On Mon, Nov 10, 2025 at 2:21 PM James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> >>> I've added support for manual mode tests >>> https://github.com/jamezp/wildfly-testing-tools?tab=readme-ov-file#manual.... >>> If things look okay, I'd like to move this to either the wildfly or >>> wildfly-extras organization as I'd like to start using it in the >>> wildfly-maven-plugin. If we don't think we want something like this, that >>> is okay too. I can just copy some things over to the wildfly-maven-plugin. >>> >>> >>> James R. Perkins >>> >>> Principal Software Engineer >>> >>> >>> On Tue, Oct 28, 2025 at 7:27 AM James Perkins <jperkins(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> James R. Perkins >>>> >>>> Principal Software Engineer >>>> >>>> >>>> On Tue, Oct 28, 2025 at 6:37 AM Brian Stansberry <bstansbe(a)redhat.com&gt; >>>> wrote: >>>> >>>>> First, just a note: if this becomes the replacement for org.wildfly.core.testrunner.WildFlyRunner then >>>>> it would be used in the main WildFly code base. WildFlyRunner is used in >>>>> testsuite/manualmode. The server lifecycle in that testsuite is not meant >>>>> to span the surefire execution and is therefore controlled by the tests >>>>> themselves. So some tests used WildFlyRunner instead of Aquillian. >>>>> >>>> >>>> This is good to know. I thought we had a rule of not using it in the >>>> WildFly test suite, but that might be wishful thinking on my part :) I >>>> currently don't support manual mode, but that should be possible to >>>> implement. >>>> >>>> >>>>> >>>>> Second, re the other tools, with that you've kind of opened the topic >>>>> of wildfly-core-testsuite-shared, which is a somewhat messy mix of common >>>>> utilities useful in testing any any stack based on the WildFly Core kernel, >>>>> and then stuff that's just meant to be shared between various testsuite >>>>> modules in WildFly Core itself. The former part being heavily used in the >>>>> main WildFly testsuite. At a very quick glance, the tools stuff in your >>>>> repo looks like more of the former. So we should think about where we want >>>>> that kind thing to live. >>>>> >>>> >>>> Agreed. That makes sense to me. The intent of this tooling is as you >>>> assumed, tooling to be used for testing with a WildFly Core based server. >>>> I'd be happy to move more utilities over as well. I'm sure there are things >>>> other projects may find helpful. >>>> >>>> >>>>> >>>>> One factor in that kind of thinking is a distinction between the >>>>> wildfly-core-testsuite-shared stuff and probably what you have in mind for >>>>> your repo is that we generally say that the wildfly-core-testsuite-shared >>>>> stuff can only be used in wildfly/wildfly-core or wildfly/wildfly. So if we >>>>> changed something and that broke someone using it some other way, we'd not >>>>> fix that if it interfered with the main needs. I'd think that if we moved >>>>> something out of wildfly-core-testsuite-shared and into wildfly-testing-tools >>>>> we'd be saying it's more broadly usable and we'd maintain it that way. >>>>> >>>> >>>> Agreed which is why it's something I've left more generic, e.g. >>>> start/stop a server, deploy an application, execute CLI commands, etc. I >>>> hadn't planned on doing some kind of ServerSetupTask, but I guess that >>>> could make sense that we could add some kind of task to execute before >>>> deployments and after an undeploy. Something like that might make sense >>>> though as we might be able to share it with WildFly Arquillian which IIRC >>>> we did try to create some kind of a bridge at one point. >>>> >>>> >>>>> >>>>> On Mon, Oct 27, 2025 at 10:47 PM James Perkins via wildfly-dev < >>>>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>>>> >>>>>> 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 >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>> List Archives: >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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