GROOVY-5227 - AbstractHttpServlet should extend GenericServlet directly instead of HttpServlet

Hi Paul, I have analyzed the ticket "GROOVY-5227 - AbstractHttpServlet should extend GenericServlet directly instead of HttpServlet" and provided Detailed Analysis, and suggested solutions on the ticket. In brief, 1. We should NOT extends GenericServlet as asked in the ticket. 2. We must either

Re: Groovy 2.5.0-beta-1 release

+1 (binding) Builds from source Signatures okay Checksums okay Cheers, Paul. On Sat, Jun 3, 2017 at 12:33 AM, Jochen Theodorou wrote: > Dear community, > > I am happy to start the VOTE thread for a Groovy 2.5.0-beta-1 release! > > This release includes 8 bug

Re: Groovy 2.5.0-beta-1 release

+1 (binding) On Fri, Jun 2, 2017 at 7:33 AM, Jochen Theodorou wrote: > Dear community, > > I am happy to start the VOTE thread for a Groovy 2.5.0-beta-1 release! > > This release includes 8 bug fixes/improvements as outlined in the > changelog: >

Re: Groovy 2.5.0-beta-1 release

+1 I checked signature of binary zip and ran a Gradle check. On Fri, Jun 2, 2017 at 12:02 PM, Daniel Sun wrote: > +1 > > Cheers, > Daniel.Sun > > > > -- > View this message in context: http://groovy.329449.n5. >

RE: using jdk9 specific API in the Groovy build

FYI, all JDK builds contain class files without method bodies shipped. It is used by the compiler, especially as Java 9 now allows the new "-release" switch. The whole stuff is in the ct.sym file (which is a JAR/ZIP file). It contains many small class files of all public APIs, but they are

using jdk9 specific API in the Groovy build

Hi all, I did spent some time to think about the problem with using JDK9 specific API in our build. One very basic problem is that the jigsaw parts of JDK9 are still in the move. API is still changing, and so do command line options. Thus let us here concentrate on