Thanks all for the replies, I hope I am posting a summary of all the feedback
1) double check with legal due to LGPL 2) need way to opt-out during development similar to checkstyle 3) patch should be in the same spirit as the other build changes, hiding details in .build and following naming 4) cool with this idea, but why not X instead? 5) rather than processing all the code, can we do a delta instead? For #2/#3 strongly agree, we should not reinvent the wheel and should follow norms (even if they are new or slowly developing as we enhance build.xml). If you wish to opt-out during development, that’s totally fine by me, though strongly feel we should guard in CI. #4, I am cool with others if they solve the problem I had, detecting lack of serialize version UID for serializable classes; this is an issue with simulator so want to make sure the tool solves this problem for us. I looked into error-prone and found its checks very limiting and lacking this check…. So if you know of a checker that solves the serialize version UID issue, I am open to switching #5. The issue I have with delta is that we need to start building “smarts” into our ant build to detect what has changed (similar to other build tools), this looks to be more work than I am willing to put into this work, but I am cool if someone else would be willing to enhance our build to be less wasteful. > On Nov 8, 2022, at 7:48 AM, Mick Semb Wever <m...@apache.org> wrote: > > > > Fair point on the name both being more representative of what it does and > being less scary. Wish we could think of something alpha-adjacent to "ant > jar" so folks that are thinking "I want to build this thing" immediately see > both options; the ant -p output is getting pretty long. > > > What's the saying when the fish can't help but bite that bait… > > the patch in my last post, it introduces aggregate skip flags, like > `-Dno-linter=` and `-Dno-docs=`, so it would also be easy to introduce a > top-level cheat like `-Dfast=` and you'd get this with > > `ant jar -Dfast=` > >
