On 05/05/2016 09:21 PM, Rostislav Svoboda wrote:
> They go into the distribution zip file.
>
ok, proper isolation in project as suggested by Alession is probably the best option.
And there will be no regression in stuff delivered in zip.
Should we move these
examples under distribution module ? These examples
should not be placed in same level with core module.
>>> -- find . | grep pom.xml | grep -v arquillian | grep -v exam | grep -v
>>> test | wc -l reports 58 pom.xml files
>>> - not clear where is the real code and what is just add-odd like examples,
>>> book stuff
>>> - naming of modules in not in sync, some are starting resteasy-*, some do
>>> not have such prefix
>>>
>>> Commits:
>>> - commit messages do not follow same/similar format - see
>>>
https://github.com/resteasy/Resteasy/commits/master
>>> -- 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.
>>> [RESTEASY-1331]
> Even better is the whole URL, so you can click and go there.
Not so sure, [RESTEASY-xxx] is the best option from my side, jira can handle integration
/ parsing of commit messages
Agree. [RESTEASY-XXX]: with some description should be
enough. We are
composing
commit message this way for wildfly, cxf and jbossws-cxf.
>>> - massive commit message like
>>>
https://github.com/resteasy/Resteasy/commit/fdd1f9f31edb894fa6f8684f26082...
>>> - 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
>> +1
>>
>>> Versions:
>>> - will leave this to Tomaz :)
>>>
>>> TS:
>>> - 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
> At some point I started adding new arquillian tests to RESTEASY-TEST-WF8
> to reduce the number of times wildfly starts up. I have a
> RESTEASY-TEST-WF10, but it depends on JDK 1.8, so it's not activated yet.
Shouldn't be JDK 8 the default ?
Public JDK 7 is not receiving updates for 1 year - see
http://www.oracle.com/technetwork/java/eol-135779.html or
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-18...
Last release was April 2015
>>> - 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
>> :-)
> A lot of tests just don't depend on the environment. I create arquillian
But there are tests which pass on tjws, but failed with WF10 / EAP7, you can check the
jira link I shared in previous email or see below
> tests only when the environment seems to matter. I agree it would be
> nice to use undertow, but who's going to take the time to do that?
There is product TS which can be reused / pulled back.
>>> 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
>> this 'internal' feature in their production env. We can't estimate
how the
>> impact will be.
Well, I'm surprised about tjws use in production environment
quick check shows this:
resteasy-jaxrs-3.0.16.Final-redhat-1.jar | grep tjws
0 02-22-2016 03:06 org/jboss/resteasy/plugins/server/tjws/
2015 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/TJWSServletDispatcher.class
2110 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/TJWSServletServer$FileMappingServe.class
5244 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/TJWSServletServer.class
1467 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/AuthenticatedHttpServletRequest.class
3172 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/TJWSRequestPreProcessor.class
3136 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/TJWSEmbeddedJaxrsServer.class
2854 02-22-2016 03:06
org/jboss/resteasy/plugins/server/tjws/PatchedHttpServletRequest.class
resteasy-spring-3.0.16.Final-redhat-1.jar | grep tjws
0 02-22-2016 03:09 org/jboss/resteasy/springmvc/tjws/
2034 02-22-2016 03:09
org/jboss/resteasy/springmvc/tjws/TJWSEmbeddedSpringMVCServer.class
1794 02-22-2016 03:09
org/jboss/resteasy/springmvc/tjws/TJWSSpringMVCDispatcher.class
2809 02-22-2016 03:09
org/jboss/resteasy/springmvc/tjws/TJWSEmbeddedSpringMVCServerBean.class
Do you know more about customer use-cases ?
> Yeah, I learned that only recently. I'm amazed. But it's true: "If
it's
> there, they'll use it."
Agree, it's bad that we realized that so late :(
Is tjws the thing we have to
support for customer? If yes, do we only
support our forked
tjws , and not the tjws upstream version ?