lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Parkes (JIRA)" <>
Subject [jira] Commented: (LUCENE-667) javacc skeleton files not regenerated
Date Mon, 30 Oct 2006 20:40:17 GMT
    [ ] 
Steven Parkes commented on LUCENE-667:

Here's the text from the javacc FAQ:

2.2  Can I modify the generated files?
Modifying any generated files should be generally avoided, since some day you will likely
want to regenerate them and then you'll have to re-modify them.
That said, modifying the, and files
is a fairly safe thing to do as the contents of these files do not depend on the options,
or the contents of the specification file, other than the package declaration. Modifying the (or file should not be done until you are certain
of your options, especially the STATIC and JAVA_UNICODE_ESCAPE options.
The custom files (,, and are produced every
time you run JavaCC. Modifying any of the custom files is generally a very bad idea, as you'll
have to modify them again after any change to the specification. Some people have written
scripts (in, say, Perl) to do the modifications for them. I would regard this as a very last

The only reason I stumbled across this is because I was using javacc 4.0 by default and it
warn/complains if you run it against  3.* genearted templates.

So I don't see a perfect answer. 4.0 people are going to get messages w/o the patch; anyone
that changes the skeleton (no matter the version) are not going to like it with the patch.
I doubt there are more of the former than the latter, but the results are worse for the latter.

So should I close this as invalid?

> javacc skeleton files not regenerated
> -------------------------------------
>                 Key: LUCENE-667
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: QueryParser
>            Reporter: Steven Parkes
>         Assigned To: Steven Parkes
>            Priority: Minor
>             Fix For: 2.1
>         Attachments: javacc.patch
> Copies of the the character stream files for javacc are checked into svn. These files
were generated under javacc 3.0 (at least that's what they say, though javacc 3.2 says this
too). javacc 4 complains that they are out of date but won't replace them; they must be removed
before it will regenerate them.
> There is one side effect of removing them: local changes are lost.  r387550 removed a
couple of deprecated methods. By using the files as generated by javacc, these deprecated
 methods will be readded (at least until the javacc team removes them totally). There are
other changes being made to the stream files, so I woudl think it's better to live with them
unmodified than to keep local versions just for this change.
> If we want javacc to recreate the files, the attached patch will remove them before running
> All the tests pass using both javacc3.2 and 4.0.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message