[ http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12445708 ] 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 Token.java, ParserException.java and TokenManagerError.java 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 SimpleCharStream.java (or JavaCharStream.java) file should not be done until you are certain of your options, especially the STATIC and JAVA_UNICODE_ESCAPE options. The custom files (XXX.java, XXXTokenManager.java, and XXXConstants.java) 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 resort. 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: http://issues.apache.org/jira/browse/LUCENE-667 > 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 javacc. > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
