thanks for having started the discussion; below some replies...
Il 04/05/2016 18:11, Rostislav Svoboda ha scritto:
>>> Moving the discussion to the mailing list ++ adding few notes about the
>>> project structure and TS.
>>> - why is there one module jaxrs in the root of repo -
>> It's added by Bill but I forget the reason. I don't like it either :-)
>> remove it now as JAX-RS is moved outside RESTEasy repo.
>>> - 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
>> him for permission to move these away.
> I think it can't cause any harm if it's just moved to separate repo under
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
The goal is to make clear what is core code related and what is not.
> - commit messages do not follow same/similar format - see
> -- I would expect jira id at the beginning of the commit message, it's
> there sometime but in different format - e.g. RESTEASY-1328 vs.
> - massive commit message like
> - commit related to RESTEASY-1323 are really "fun"
> -- https://github.com/resteasy/Resteasy/pull/756/files
> -- one fix in code (4 lines removed) + two tests done in 7 commits :(
> -- these commits should have been squashed
Yeah, it should be easy to be a little bit more accurate with the commit
messages. As for the jira reference, it should always be like
"[RESTEASY-XYZ]" and there's no actual need to include the jira URL as
jira can be configured to automatically parse references in commit
messages to link commits to related issues.
>>> - will leave this to Tomaz :)
>>> - unit tests are mixed with integration tests
>>> -- integration tests should be in separate module
>>> -- tests should be running in different maven phases
>>> - there are only few tests against WF
>>> - such tests are not executed against latest WF, but mainly against WF 8
>>> - I would like to see ARQ + WF10+ and get rid of tjws
>> Get ridding of TJWS is not practical because it will make the test time
>> unacceptable. But replacing them with undertow container would be great
> Do you have estimation how much time tjws saves ? And PRs are processed on
> external system (Travis atm) so I wouldn't be bothered if the TS runs for
> few minutes longer.
> As proven by EAP QE internal resteasy testsuite, it's not revealing issues
> which could be eliminated before RESTEasy goes into the product.
> For me Undertow container is not sufficient from product perspective, WF is
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
+1, run server just once, run 90+% of tests against it. Some tests may need additional
configuration, or be executed in forked mode etc.
Ideally (I understand that might not be doable for any type of test),
would really be cool to able to select the target container among wfly
and other available integrations (jetty, tjws, etc), so that we only
maintain a set of tests and it's then up to the CI system to verify they
pass against all supported targets (a run for each target, perhaps
specifying it with a different profile)
Jetty and Tomcat have ARQ integration for sure.
>>> EAP 7 situation for TS:
>>> - we migrated upstream ts to use ARQ and run against EAP 7 and not tjws
>>> - we discovered half of reported issues thanks to this migrated TS, these
>>> issues wouldn't be noticed bu community TS executed against tjws
>> Totally removing TJWS is also not possible, because many users are using
>> 'internal' feature in their production env. We can't estimate how
>> will be.
Sure, but if we feel that's the right thing to do, we can deprecate the
tjws integration in a 3.0.x version and remove it in next major.
+1, we need to follow best practice and deprecate stuff first.
>> We can try to remove TJWS for testing purposes in RESTEasy project itself.
Yes, but see above
>> But the RESTEasy TJWS module should be maintained as a feature.
> I think it should be moved into separate repository with own release cycle.
> Not even sure if it should be under https://github.com/resteasy
, but for
> now it would be sufficient ... I guess
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
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 ;)
>>> -- 19 from 38 jiras -
>>> - we will keep this TS for 7.0.z
>>> - we would like to consume & prod-patch upstream (ARQ + WF based) TS
>>> the future releases
>>> Upstream and QE specific TS should somehow converge into a single one.
> This can only happen if the TS runs against WF as EAP is based on WF.
> ARQ here for some time and it is really preferred from our side.
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
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
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.
Web Service Lead, JBoss
resteasy-dev mailing list