You only need to regenerate the parser files when there is something wrong with the grammar or the grammar needs improving.
I did not make it so that each build regenerates the grammar. "ant parser" will regenerate the grammar, creating updated *.java files. "ant jar" will build the project. They remain two separate and independent commands. There's a specific regression that happened between 1.3.1 and 1.4 that I need to fix to use velocity: #set<tab> is no longer working -- only space is recognized as whitespace between #set and the left parenthesis. Jira issue with patch to be created in the near future, but the bug was mentioned on the mailing list a year ago. I don't know the answer to the maven question, but I think Will was going to look at the maven parser in any case. I suspect that changing the javacc version could be an issue, though, as it probably impacts other generated files. I seem to recall trying to build the parser with javacc 6 last year and failing miserably, but I haven't tried recently enough to remember any specific details. On Fri, May 29, 2015 at 5:33 PM, Frederick N. Brier <fnbr...@gmail.com> wrote: > So this whole thread about javacc made me realize I was using the parser > source files that were checked in and I was not regenerating the parser with > each build. I started to look at how to do that and realize that many of > the files had been modified, modified and copied, and that may be why they > were just checked in. It sounds like Mike just set it up so every build is > now regenerating the parser? Or was that happening before and I missed it > when I converted from Ant to Maven? > > Also, I noticed that javacc us up to release 6.1.2 and the associated Maven > plugin is 2.6. Is there a problem moving to 6.1.2 and sticking with 4.2? > Should I change my Maven build to regenerate the parser? Or is it enough > that I pushed my code to Github. Thank you. > > Fred > > > On 05/29/2015 06:59 AM, Mike Kienenberger wrote: >> >> 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 >> > > > --------------------------------------------------------------------- > 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
