Re: [resteasy-dev] RESTEasy and possible "community" contribution

> >>>> - there are too many modules (in root jaxrs module) from my perspective >>>> -- multi module project structure can affect build time >>>> -- find . | grep pom.xml | wc -l reports 226 pom.xml files >>> The 'example' module contains all the Bill's book examples. We need to ask >>> him for permission to move these away. >> I think it can't cause any harm if it's just moved to separate repo under >> https://github.com/resteasy > I don't think we actually need an additional repo for the examples and > books stuff, what we really need (as you actually already pointed out) > is having them clearly isolated, which means: > * everything under 'examples' dir > * clear maven group and artifact naming (let's say, anything in there > should have a "resteasy-examples-" prefix or something like that) > That way we can keep on including the examples etc in the distro while > reducing clutter in the IDE (you simply avoid including the examples > stuff when importing the project and in any case the examples maven > modules are all close together and in order). I'm ok with that if examples are part of regression tests bundle and will be executed regularly. The goal is to make clear what is core code related and what is not.

> I'm also for using WildFly as the default and preferred testing > container, unless an issue related to a different container integration > is being worked/tested. I would even propose to do something like what > we do in JBossWS, that is test against the latest 3 final releases of > WildFly + current master (to anticipate integration issues). > The project build should be able to build the required artifacts, > install them on the specified wildfly target instance, start it and run > the testsuite against it. > While starting a container instance for each (integration)test and > stopping it as soon as the test is over is nice, if you think about that > it's not really required. We should always ensure tests are idempotent, > that is they leave the target container unchanged after their execution; > once that's granted, we can run multiple tests against the same server, > no need to keep on starting and stopping it, which is what really takes > time. With a proper deployment name isolation, it should also be > possible to run multiple tests at the same time against the same target > server. +1, run server just once, run 90+% of tests against it. Some tests may need additional configuration, or be executed in forked mode etc.

> We *could* have the integrations live in different components/repos, > similarly to what we have in jbossws, but that comes with release and > maintenance costs, so I won't do that unless there's real benefit in the > move. I still feel that tjws shouldn't be tightly coupled with restreasy. It's just slim container and there are more containers which can be used for resteasy and these containers are not included in the codebase ;) Just pull it out and release it once. And we are done, no additional costs ;)

> I agree on both the WF target reasoning and on using Arquillian. > > > Finally, not sure where to comment on this, anyway I won't isolate the > TS too much from the rest of the code. I agree on moving the integration > tests to dedicated project module(s), but those should live in the same > repo and by triggered by the same build of the resteasy core. Ok, I'm fine with described procedure, we have this in jbossws and we as qe can handle that. My idea is that the integration testsuite module doesn't need to reference resteasy core parent/root - <parent> stuff. Integration testsuite module would be referenced in <modules> section of root pom.xml Integration testsuite module would define/control own dependencies + resteasy dependencies version would be same as the version of the integration testsuite module. Another option is to strictly define just dependency management and plugin management in root pom.xml and reference only needed deps in particular modules.