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

Reply via email to