In what sense is JavaCC a "dependency of the activemq-client package"? It's not a Maven dependency, and it's not shipped with the broker. It's simply part of the build process and represents a near-zero maintenance burden.
I'm against checking in the generated source and removing the integration with JavaCC for the following reasons: - You never know what changes will be required in the future. Generally speaking, you'd want to modify the JavaCC input rather than the JavaCC output in that case. - If there is ever any improvement to JavaCC we won't benefit from it. - There is no real downside to keeping the existing structure in place. Artemis uses the same basic process to generate the selector parser, and it uses JavaCC 7.0.13 without issue. What is the benefit of removing the integration and checking in the generated code? Justin On Fri, Jan 17, 2025 at 3:49 AM Ken Liao <kenlia...@gmail.com> wrote: > Hi folks, > > Recently, I am diving into the SelectorParser.java generated by javacc. I > am wondering, do we want to keep maintaining javacc as a dependency of the > activemq-client package? > > In another word, the grammar of the JMS selector hasn't changed (last time > the change made to the grammar definition file SelectorParser.jj is > changing the namespace to jakarta in the main branch). Would it be easier > to just commit the generated java file as source and remove the javacc > dependency? > > If we do want to keep it as a dependency, the latest stable release of > javacc is version 7. I can upgrade javacc to version 7 to check if it > breaks the build and tests. I will create a PR on it soon if there's no > objection. > > Thanks, > Ken >
