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

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 ?

_______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev