You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Mike Kienenberger <mk...@gmail.com> on 2015/05/29 14:48:16 UTC
Re: Successfully building 1.x branches and regenerating parser files
On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger <mk...@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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <fn...@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 <mk...@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
>>> <se...@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
>>>>> <mk...@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-unsubscribe@velocity.apache.org
>>>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>>>
>>>>
>>>> --
>>>> Sergiu Dumitriu
>>>> http://purl.org/net/sergiu/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
Posted by "Frederick N. Brier" <fn...@gmail.com>.
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 <mk...@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
>> <se...@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 <mk...@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-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>>
>>>
>>> --
>>> Sergiu Dumitriu
>>> http://purl.org/net/sergiu/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mk...@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
> <se...@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 <mk...@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-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>
>>
>>
>> --
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
Posted by Mike Kienenberger <mk...@gmail.com>.
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
<se...@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 <mk...@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-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Successfully building 1.x branches and regenerating parser files
Posted by Sergiu Dumitriu <se...@gmail.com>.
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 <mk...@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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org