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
