I agree with Justin here. What is the need to remove the dependency on javacc - especially since it is build-time only?
Art On Fri, Jan 17, 2025 at 1:11 PM Justin Bertram <jbert...@apache.org> wrote: > 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 > > >
