I have created issues 861 (improve parser documentation) and 862 (fix parser import generation) to clean up the parser building process.
https://issues.apache.org/jira/browse/VELOCITY-861 https://issues.apache.org/jira/browse/VELOCITY-862 On Fri, May 29, 2015 at 9:33 AM, Mike Kienenberger <mkien...@gmail.com> wrote: > 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