I've already created issue 860 and I have already attached individual patches for fixing the build scripts in 1.5, 1.6.x, and 1.7.x branches.
https://issues.apache.org/jira/browse/VELOCITY-860. Modifying unusable build files to point to the right download locations is one thing, but I'm on the fence about whether we should change the 1.3.1 or 1.4 java files to make them build on newer versions of java. Using an older version of java or possibly using a source & target javac flag leaves them usable as is. If a person really wants to make them work under a newer version of java, it's easy to rename the variables, but that would have to be done each time the parsing files are regenerated using the older javacc packages. I am currently in the process of updating the build instructions for the parser, and removing the old build.sh script -- it only adds confusion now that the main build script does everything necessary. I should be finished with that in a couple of minutes. On Fri, May 29, 2015 at 9:03 AM, Sergiu Dumitriu <sergiu.dumit...@gmail.com> wrote: > Good work! > > Mike, could you provide these instructions as patches, one for each branch? > > So, given that getting a working build for the 1.7.x branch is actually > quite easy, we could quickly fix a couple of things and release 1.7.1. > Does any committer want to take the lead on that? > > On 05/29/2015 08:48 AM, Mike Kienenberger wrote: >> On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger <mkien...@gmail.com> >> wrote: >>> 1.3 and 1.4 won't build without some code changes -- they use enum as >>> a variable. >> >> These were generated parser files. A find and replace of enum to enmr >> was all that was needed. Or going back to java 1.3 :) >> >>> Parser modification also seems possible now, although the large number >>> of changes between my generated code and the old generated code seems >>> to indicate that I'm still not using the same version of javacc that >>> the original code was generated from. 1.6 is a close enough match >>> that I suspect it uses javacc 3.2. That probably means 1.5 was >>> generated with something older and 1.7 was generated with something >>> newer. >> >> Part of the differences turned out to be code reformatting of the >> generated files. Velocity 1.5 used javacc 3.1. 1.6 used javacc 3.2. >> Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be >> manually reverted manually after running the parser task. The newly >> generated JJTParserState only changes the file checksum and loses the >> org.apache.velocity.runtime.parser.node.Node import. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >> For additional commands, e-mail: dev-h...@velocity.apache.org >> > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
