Bump foojay-resolver-convention to 1.0.0 for Gradle 9.6.1 compatibility - #756
Closed
ghedwards wants to merge 134 commits into
Closed
Bump foojay-resolver-convention to 1.0.0 for Gradle 9.6.1 compatibility#756ghedwards wants to merge 134 commits into
ghedwards wants to merge 134 commits into
Conversation
…nore lines were incorrect
Fix matching on @CFLintIgnore comments
QueryParamChecker returning a lot of matches, include addition of parameters to exclude code base exclusions such as use of cfloop and common delimiter ( clauseDelim|delim) variables
"QueryParamChecker.allowVariableExpression":"(clauseDelim|delim)",
"QueryParamChecker.allowLineExpression":"<cfloop[^>]*#${variable}#[^>]*>"
bugInfo.getColumn() is returning negative values in some cases, ensure when output to text is does not return a negative column.
bugInfo.getColumn() is returning negative values in some cases
Queryparamchecker fix
Merge from upstream
The syntax for creating an HTML-file in README.MD is incorrect "-html -html <outputfile>" should be "-html -htmlfile <outputfile>" according to the integrated help function
cflint#662 Fixing 501 errors
Upgraded http to https
Update file change
Update Docker Gradle
Increment version to v1.5.1-SNAPSHOT
…CaseChecker Fix/memory leak in package case checker
bugInfo.getColumn() is returning negative values in some cases
Fix for findbug xml output
Queryparamchecker fix
Bumps [com.fasterxml.jackson.core:jackson-core](https://github.com/FasterXML/jackson-core) from 2.16.1 to 2.18.6. - [Commits](FasterXML/jackson-core@jackson-core-2.16.1...jackson-core-2.18.6) --- updated-dependencies: - dependency-name: com.fasterxml.jackson.core:jackson-core dependency-version: 2.18.6 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
- Update jackson.version - Add --add-opens to maven surefire configuration
Picks up the expression and dictionary caching work along with the correctness fixes that followed it. The pin was on 2.15.0-SNAPSHOT, which predates the caching entirely, so none of it was reaching CFLint. The version is declared separately in pom.xml and build.gradle, so both are updated; a Maven-only bump would leave the Gradle build resolving the old artifact. Blocked until cfparser 2.15.2-SNAPSHOT is published - cfparser publishes only on GitHub release creation, and the release has not been cut yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GzpZFd4rnE1Yi2sVHAji35
cfparser now compiles at Java 21, so its artifacts are class file version 65 and cannot be loaded by an 11 JVM. Building against 2.15.2-SNAPSHOT therefore requires moving this build to 21 as well: - pom.xml maven.compiler.source/target 11 -> 21 - build.gradle toolchain languageVersion 11 -> 21 - gradle.yml and publish.yml runners 11 -> 21 native-release.yml already uses JDK 25 and is unaffected. This also fixes the Gradle CI, which has been red on master since 6 July: the wrapper was upgraded to Gradle 9.6.1, which requires JVM 17 or later to run, while the workflow kept supplying 11. Moving to 21 satisfies both that and the new cfparser baseline. Verified: mvn clean test passes 675 tests at Java 21 against cfparser 2.15.2-SNAPSHOT. The Gradle build could not be exercised locally - the toolchain pins the Adoptium vendor and this environment has a non-Temurin JDK 21 with no route to the foojay resolver - so that half is left to CI, where setup-java supplies temurin 21 and satisfies the pin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GzpZFd4rnE1Yi2sVHAji35
Move to JDK 21 and cfparser 2.15.2-SNAPSHOT
The build & test section still said Java 11, which stopped being true when the baseline moved to 21 to follow cfparser. Records which four places carry the Java version, since they have to move together. Expands the dependency note with the things that make a cfparser bump look successful when it is not: the version is declared twice (pom.xml property and a hardcoded coordinate in build.gradle, the latter being what CI actually builds), upstream publishes only on tag/release/dispatch so merging there changes nothing here, and Gradle caches SNAPSHOT modules for 24 hours so a green run just after a republish may have used the previous artifact. Also notes that parseCFMLExpression is the cached entry point this repo calls, and that a parser is constructed per file. Adds a bump-cfparser skill covering that workflow end to end, including how to tell "CI is green" apart from "CI exercised the new artifact". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GzpZFd4rnE1Yi2sVHAji35
Update CLAUDE.md for the Java 21 baseline and add a bump-cfparser skill
Records that a resolution failure names the wrong repository. The allow-snapshots profile in pom.xml is activeByDefault and adds Sonatype's snapshot repo, which Maven tries before the github repo that actually hosts cfparser - so an unpublished artifact and an unreachable network both surface as a Sonatype error, and neither message means what it appears to. Adds the control that tells them apart: re-resolve a version known to exist, and if that fails identically the environment is the problem and the run says nothing about publication. Also notes two grep decoys - commons-io:2.15.1 matches a naive version search, and the tracked pom.xml.versionsBackup pins a dead 2.6.0 under the old groupId - and that CHANGELOG.md is generated by the gitChangelog task, so a hand-written entry is overwritten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GzpZFd4rnE1Yi2sVHAji35
Refine the bump-cfparser skill with two diagnostics from evaluation runs
Picks up the grammar work merged upstream since 2.15.2-SNAPSHOT, which was published on 10 August and carried only the Java 21 baseline. Both declarations moved: the cfparser.version property in pom.xml and the hardcoded coordinate in build.gradle. Gradle is what CI runs, so a Maven-only bump would pass locally while CI kept compiling against the old artifact. Java baseline needs no change -- cfparser and CFLint are both already on 21. 675 tests pass under Maven, with dependency:tree confirming cfml.parsing and cfml.dictionary both resolve at 2.16.0-SNAPSHOT. Upstream added lexer tokens, which renumbers every token constant, so this is a recompile rather than a drop-in jar swap -- isExpectedToken(CFSCRIPTParser.SEMICOLON) inlines that constant into CFLint's bytecode.
…apshot Bump cfparser to 2.16.0-SNAPSHOT
master sat on 1.5.14, the released version, so there was no snapshot coordinate carrying the cfparser 2.16.0-SNAPSHOT grammar work merged in #56. Anyone wanting those parser fixes had to build CFLint themselves. publish.yml triggered only on release: created, so a snapshot could not be published at all without cutting a release. Adding workflow_dispatch matches what cfparser's publish workflow already allows and makes snapshot publishing possible without minting a version tag. Verified: 675 tests, and a deploy against a local file repository produces cflint-1.5.15-SNAPSHOT.jar, the -all fat jar and the pom, routed through maven-deploy-plugin. Note nexus-staging sits inside the deploy profile here, not the main build, so it does not hijack the deploy phase the way it did in cfparser (#58). Release publishing on this side already works -- 1.5.14 published green.
Publish 1.5.15-SNAPSHOT, and let the publish workflow be dispatched
…e-jackson-core-2.18.6
….jackson.core-jackson-core-2.18.6 Bump com.fasterxml.jackson.core:jackson-core from 2.16.1 to 2.18.6
Plugin 0.8.0 references JvmVendorSpec.IBM_SEMERU, a field that doesn't exist on Gradle 9.6.1's JvmVendorSpec, so toolchain resolution/auto- provisioning crashes with NoClassDefFoundError/NoSuchFieldError before any project configuration completes, breaking every build (even ones that don't need to provision a toolchain). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Author
|
Opened against the wrong repository by mistake (gh defaulted to the fork parent). Closing — correct PR will be opened against cfmleditor/CFLint. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
settings.gradlepinnedorg.gradle.toolchains.foojay-resolver-conventionto0.8.0, which is incompatible with Gradle 9.6.1.JvmVendorSpec.IBM_SEMERU, a field that doesn't exist on Gradle 9.6.1'sJvmVendorSpec. Any time toolchain resolution runs, it fails withNoSuchFieldErrorwrapped inNoClassDefFoundError/ExceptionInInitializerError, which aborts project configuration before the build graph is even calculated — so no task can run.1.0.0resolves it; that's the version this plugin's API actually lines up with on Gradle 9.6.1.Test plan
./gradlew build(compile + test + jar) runs cleanly on Gradle 9.6.1 with a real JDK 21 toolchain available locally.NoSuchFieldErrorroot cause with--stacktracebefore the change).🤖 Generated with Claude Code