Bump gson from 2.8.7 to 2.8.8 - #12
Merged
Merged
Conversation
Bumps [gson](https://github.com/google/gson) from 2.8.7 to 2.8.8. - [Release notes](https://github.com/google/gson/releases) - [Changelog](https://github.com/google/gson/blob/master/CHANGELOG.md) - [Commits](google/gson@gson-parent-2.8.7...gson-parent-2.8.8) --- updated-dependencies: - dependency-name: com.google.code.gson:gson dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
deleted the
dependabot/maven/com.google.code.gson-gson-2.8.8
branch
August 23, 2021 04:54
Merged
This was referenced Apr 13, 2026
tae898
pushed a commit
to humemai/arcadedb-embedded-python
that referenced
this pull request
Jun 28, 2026
….google.code.gson-gson-2.8.8 Bump gson from 2.8.7 to 2.8.8
lvca
added a commit
that referenced
this pull request
Aug 1, 2026
…med records only CHECK DATABASE could be narrowed to a TYPE or a BUCKET, but not to a record. That is the sharp edge of the strict vertex delete merged in #5707: a genuinely broken edge chain makes its vertex undeletable until CHECK DATABASE ... FIX rebuilds the adjacency from the surviving edge records, and the smallest way to ask for that repair was two full passes over the whole vertex type. CHECK DATABASE RECORD #12:3 FIX CHECK DATABASE RECORD #12:3, #12:9 FIX The per-record work and the fix are identical to the type-wide run, including the edge-list rebuild; only the enumeration changes. Combines with FIX and COMPRESS. Rejected when combined with TYPE or BUCKET - RECORD is already the narrowest scope, so letting one silently win would run a check nobody asked for and an intersection would be a third semantics nobody asked for. The database-wide passes (buckets, external properties, indexes) and the orphaned-segment reclaim are skipped, since none can be narrowed to a record. Two costs it deliberately does not bound, documented rather than glossed: rebuilding an adjacency needs every surviving edge that points at the vertex and no index maps endpoints back to edges, so the scoped run saves the vertex passes but still scans the edge types; and a listed record that turns out to be corrupted still has every index on its bucket rebuilt. Also fixes a vacuously-passing assertion in Issue5670EdgeDeleteDanglingBackRefTest: it asserted totalErrors == 0, and check database reports no such field, so the null-tolerant reader turned it into 0 == 0 on every run whatever the check found. It now asserts on autoFix, invalidLinks, totalWarnings and totalCorruptedRecords, and fails loudly on a field that does not exist.
lvca
added a commit
that referenced
this pull request
Aug 2, 2026
…med records only (#5710) * feat(engine) #5680: CHECK DATABASE RECORD <rid> checks and repairs named records only CHECK DATABASE could be narrowed to a TYPE or a BUCKET, but not to a record. That is the sharp edge of the strict vertex delete merged in #5707: a genuinely broken edge chain makes its vertex undeletable until CHECK DATABASE ... FIX rebuilds the adjacency from the surviving edge records, and the smallest way to ask for that repair was two full passes over the whole vertex type. CHECK DATABASE RECORD #12:3 FIX CHECK DATABASE RECORD #12:3, #12:9 FIX The per-record work and the fix are identical to the type-wide run, including the edge-list rebuild; only the enumeration changes. Combines with FIX and COMPRESS. Rejected when combined with TYPE or BUCKET - RECORD is already the narrowest scope, so letting one silently win would run a check nobody asked for and an intersection would be a third semantics nobody asked for. The database-wide passes (buckets, external properties, indexes) and the orphaned-segment reclaim are skipped, since none can be narrowed to a record. Two costs it deliberately does not bound, documented rather than glossed: rebuilding an adjacency needs every surviving edge that points at the vertex and no index maps endpoints back to edges, so the scoped run saves the vertex passes but still scans the edge types; and a listed record that turns out to be corrupted still has every index on its bucket rebuilt. Also fixes a vacuously-passing assertion in Issue5670EdgeDeleteDanglingBackRefTest: it asserted totalErrors == 0, and check database reports no such field, so the null-tolerant reader turned it into 0 == 0 on every run whatever the check found. It now asserts on autoFix, invalidLinks, totalWarnings and totalCorruptedRecords, and fails loudly on a field that does not exist. * style(engine) #5680: strip trailing whitespace flagged by pre-commit The setup job failed on a trailing-whitespace line an earlier edit left after a comment in the RECORD-scoped edge branch. Removed, along with the stray blank line beside it. * fix(engine) #5680: a missing RID is not corruption, and the scoped progress step stops double-counting Two independent review passes on the RECORD scope, four actionable points between them. - A listed RID that simply is not there was recorded through addCorrupted, which puts its BUCKET into affectedBuckets - so CHECK DATABASE RECORD ... FIX dropped and rebuilt every index on that bucket, a full bucket scan, over what is usually a mistyped or already-deleted RID. That is exactly the cost the scope exists to avoid, and the scope is meant to be hand-typed after a failed delete. RecordNotFoundException is now reported and never flagged corrupted, in all three arms (vertex, edge, document). Mutation-checked: restoring addCorrupted fails the new test with totalCorruptedRecords=1, autoFix=1. - checkScopedRecords bumped currentStep for every group, but the document arm reaches stepBegin, which bumps it again - so a scope containing a plain document reported "step 3 of 2" against a totalSteps budgeted at one step per group. Each arm now owns its bump; the graph arms need it because they pass a fixed value into the nested GraphDatabaseChecker instead. - setRecords and the statement's stream now drop null RIDs. Rid.toRecordId can answer null for a non-literal form, and groupRecordsByType would meet it as an NPE on getBucketId(). Not reachable through the RECORD #n:n literal grammar, but setRecords(Set<RID>) is public API. - The parser test's cross-reference named a test class that no longer exists after the rescope. Tests: four added for the branches that were unexercised - an edge-typed RID, a document-typed RID (the branch the progress bug lived in), several RIDs spanning different types in one command, and a missing-but-valid RID under FIX, which pins the first item above. * fix(engine) #5680: a RECORD scope that resolves to nothing is refused, not widened to the whole database Review round on the rescoped PR: LGTM with three minor points, two taken. - CHECK DATABASE RECORD whose RIDs all resolve to null left the checker with an empty scope, which reads as "no scope" - so a command that explicitly named records quietly ran a FULL database check. The review judged this unreachable from SQL; it is not. Only the `#n:n` literal always resolves, while the non-literal {"@Rid": <expression>} form goes through an expression that can answer null, so `CHECK DATABASE RECORD {"@Rid": null}` reached it. Refused now, with a test that fails when the guard is stubbed out. - A warning dropped for exceeding maxWarnings was discarded silently in the two scoped arms, where GraphDatabaseChecker.addWarning logs it. Extracted addScopedWarning so both behave the same: always counted, retained under the cap, logged when dropped. Not taken: extracting the duplicated RecordNotFoundException/Exception catch blocks in the scoped vertex and edge arms. They would need six accumulators threaded through a shared helper, which reads worse than the duplication, and the surrounding type-wide methods already parallel each other the same way - the review noted as much in raising it. * fix(engine) #5680: the empty-scope guard moves into setRecords, so it protects the public API too Review round: LGTM once the setRecords widening note was considered. Went one step further than the note it asked for. The guard against "a RECORD scope that resolves to nothing silently becomes a full database check" lived only in the SQL layer, so an embedded caller reaching DatabaseChecker.setRecords directly still hit the widening. The review reasoned that setRecords cannot tell "named records, none usable" from "named no records" - true only because the SQL layer filtered the nulls out BEFORE calling it. It no longer does: the nulls are passed through, setRecords owns both the filtering and the refusal, and one guard now covers both entry points. A genuinely empty (or null) set still means "no scope" and is accepted. Both are asserted. Also: the document arm said "cannot be loaded, removing it", but nothing removes the record there - corruptedRecords only drives the index rebuild. The review called the wording inherited and asked for no action; it is new code here, so it now says what is true, with a note on why it diverges from the type-wide checkDocuments (which also calls a document a "vertex"). Adds the warning-cap test the review asked for: 40 bogus RIDs against maxWarnings=10 retains 10 messages and still counts 40. Not added: an execution test for RECORD ... FIX COMPRESS. The compress pass is shared, unscoped code already covered elsewhere, and routing it through the scoped enumeration exercises no new branch. * docs(engine) #5680: state the COMPRESS caveat, and pin the corrupted-record fix cost with a test Review approved with three non-blocking notes; two taken. - COMPRESS is unaffected by the RECORD scope and still compresses the whole database. It is opt-in, but it is the one clause that breaks the "naming a record bounds the cost" promise, so it now sits in the release notes beside the other two costs the scope does not bound. - Added the test the review asked for: a listed record that is GENUINELY corrupted - not merely missing, not merely chain-broken - is flagged, and under FIX every index on its bucket is dropped and rebuilt. That turns the "RECORD bounds the check, not necessarily the fix" paragraph into an executable assertion, so a future change cannot quietly make a scoped repair either cheaper or more destructive than documented. Mutation-checked: dropping addCorrupted from the scoped arm fails it, and the injected corruption is the intended shape (buffer truncated to 8 bytes against the 25-byte vertex prefix), distinct from the missing-RID path. Not taken: moving the RECORD-plus-TYPE/BUCKET rejection from check() into the setters. setTypes and setRecords can be called in either order, so a setter-level guard would fire or not depending on call order; check() is the only place that sees the whole configuration. The review called the current placement acceptable. * fix(engine) #5680: a dropped RID is reported, the no-type step is named, and a comment stops overselling Review round: approve, all notes minor. Three taken. - The "Exception, not Throwable" comment claimed more protection than the code gives. It guards the LOOKUP, but the shared per-record consumer still catches Throwable around the connectivity check itself - matching the type-wide path, which is why it stays. The comment now says exactly what is and is not covered rather than implying an Error can never be recorded as corruption. - setRecords refused an all-null scope but dropped a PARTIAL one silently, so a caller who mistyped one of several RIDs got a clean report for a check that skipped it. Narrowing is still allowed - unlike widening it cannot do more than asked - but it now surfaces a warning naming how many were dropped, with a test. - The no-type group advanced currentStep without ever naming the step, so a progress poller watched it go by blank. Routed through stepBegin like the document arm, which also owns the bump. Not taken: - Rejecting RECORD together with COMPRESS for symmetry with the TYPE/BUCKET rejection. The two are not the same case: RECORD plus TYPE/BUCKET has no coherent meaning, whereas "check this record, then compress the database" is perfectly meaningful - it is just not cheap. That is a documentation problem, and the release note now states it. - @tag("slow") on the 200-edge tests. Measured rather than assumed: the whole class runs in 0.53s, and CLAUDE.md's criteria are multi-second elapsed or large batches. 200 tiny transactions under a second is neither. * fix(engine) #5680: diagnose the clause conflict first, warn that COMPRESS is unscoped Review round: refinements, not blockers. Four taken. - CHECK DATABASE TYPE Hub RECORD {"@Rid": null} reported "none of them resolves to a RID", because the RIDs are resolved before check() reaches the combination guard - pointing the operator at the inner failure while the actual mistake is the clause combination. The statement now diagnoses the combination before resolving anything; check() keeps its own guard for programmatic callers. - setRecords left droppedRecords stale on its early-return path. Harmless today, since the warning is only emitted under a record scope, but the field is public-API-visible state and should not depend on call order. - COMPRESS now warns that it is not limited by the RECORD scope. The review suggested this as a middle ground between refusing the combination and staying silent, and it is a better answer than the documentation-only one: the command still does what it was asked, but an operator who named a record and expected a bounded run is told otherwise. Tested both ways, so the warning tracks the clause rather than the scope. - Recorded, not fixed: the type-wide checkDocuments adds to the warnings/corrupted sets without incrementing the corresponding totals, so a corrupt document reports different totals depending on which path found it. The scoped arm here is the correct one; aligning the type-wide path is a behaviour change to a command this issue does not otherwise touch. Agreed with the review that the duplicated catch blocks read better than threading six accumulators through a shared helper; no change. * fix(engine) #5680: one owner for the conflict message, no counts a Set cannot know, bounded corrupted set Review round: nothing blocking. All four points taken. - The "cannot be combined with TYPE or BUCKET" text was written out in both the statement and the checker. The two-layer guard stays - the statement has to diagnose the clause conflict before the RIDs are resolved - but the wording now lives in one constant so the two cannot drift. - Two messages quoted a record count the Set could not know: several RID expressions that all resolve to null collapse to a single null element, so "given 3 record(s)" was never reachable and "1 of the record(s) did not resolve" under-reported. Rather than plumb the original count through, both messages stop quoting a number, which is accurate whatever the input. - checkScopedDocuments grew corruptedRecords without a bound while every other path honours maxCorrupted/maxWarnings. Bounded the same way, with the total still counting every occurrence. - Documented that the edge sweep a rebuild needs runs once per distinct vertex TYPE named, not once per run: ten vertices of one type cost one sweep, one vertex of each of three types cost three.
robfrank
pushed a commit
that referenced
this pull request
Aug 14, 2026
…med records only (#5710) * feat(engine) #5680: CHECK DATABASE RECORD <rid> checks and repairs named records only CHECK DATABASE could be narrowed to a TYPE or a BUCKET, but not to a record. That is the sharp edge of the strict vertex delete merged in #5707: a genuinely broken edge chain makes its vertex undeletable until CHECK DATABASE ... FIX rebuilds the adjacency from the surviving edge records, and the smallest way to ask for that repair was two full passes over the whole vertex type. CHECK DATABASE RECORD #12:3 FIX CHECK DATABASE RECORD #12:3, #12:9 FIX The per-record work and the fix are identical to the type-wide run, including the edge-list rebuild; only the enumeration changes. Combines with FIX and COMPRESS. Rejected when combined with TYPE or BUCKET - RECORD is already the narrowest scope, so letting one silently win would run a check nobody asked for and an intersection would be a third semantics nobody asked for. The database-wide passes (buckets, external properties, indexes) and the orphaned-segment reclaim are skipped, since none can be narrowed to a record. Two costs it deliberately does not bound, documented rather than glossed: rebuilding an adjacency needs every surviving edge that points at the vertex and no index maps endpoints back to edges, so the scoped run saves the vertex passes but still scans the edge types; and a listed record that turns out to be corrupted still has every index on its bucket rebuilt. Also fixes a vacuously-passing assertion in Issue5670EdgeDeleteDanglingBackRefTest: it asserted totalErrors == 0, and check database reports no such field, so the null-tolerant reader turned it into 0 == 0 on every run whatever the check found. It now asserts on autoFix, invalidLinks, totalWarnings and totalCorruptedRecords, and fails loudly on a field that does not exist. * style(engine) #5680: strip trailing whitespace flagged by pre-commit The setup job failed on a trailing-whitespace line an earlier edit left after a comment in the RECORD-scoped edge branch. Removed, along with the stray blank line beside it. * fix(engine) #5680: a missing RID is not corruption, and the scoped progress step stops double-counting Two independent review passes on the RECORD scope, four actionable points between them. - A listed RID that simply is not there was recorded through addCorrupted, which puts its BUCKET into affectedBuckets - so CHECK DATABASE RECORD ... FIX dropped and rebuilt every index on that bucket, a full bucket scan, over what is usually a mistyped or already-deleted RID. That is exactly the cost the scope exists to avoid, and the scope is meant to be hand-typed after a failed delete. RecordNotFoundException is now reported and never flagged corrupted, in all three arms (vertex, edge, document). Mutation-checked: restoring addCorrupted fails the new test with totalCorruptedRecords=1, autoFix=1. - checkScopedRecords bumped currentStep for every group, but the document arm reaches stepBegin, which bumps it again - so a scope containing a plain document reported "step 3 of 2" against a totalSteps budgeted at one step per group. Each arm now owns its bump; the graph arms need it because they pass a fixed value into the nested GraphDatabaseChecker instead. - setRecords and the statement's stream now drop null RIDs. Rid.toRecordId can answer null for a non-literal form, and groupRecordsByType would meet it as an NPE on getBucketId(). Not reachable through the RECORD #n:n literal grammar, but setRecords(Set<RID>) is public API. - The parser test's cross-reference named a test class that no longer exists after the rescope. Tests: four added for the branches that were unexercised - an edge-typed RID, a document-typed RID (the branch the progress bug lived in), several RIDs spanning different types in one command, and a missing-but-valid RID under FIX, which pins the first item above. * fix(engine) #5680: a RECORD scope that resolves to nothing is refused, not widened to the whole database Review round on the rescoped PR: LGTM with three minor points, two taken. - CHECK DATABASE RECORD whose RIDs all resolve to null left the checker with an empty scope, which reads as "no scope" - so a command that explicitly named records quietly ran a FULL database check. The review judged this unreachable from SQL; it is not. Only the `#n:n` literal always resolves, while the non-literal {"@Rid": <expression>} form goes through an expression that can answer null, so `CHECK DATABASE RECORD {"@Rid": null}` reached it. Refused now, with a test that fails when the guard is stubbed out. - A warning dropped for exceeding maxWarnings was discarded silently in the two scoped arms, where GraphDatabaseChecker.addWarning logs it. Extracted addScopedWarning so both behave the same: always counted, retained under the cap, logged when dropped. Not taken: extracting the duplicated RecordNotFoundException/Exception catch blocks in the scoped vertex and edge arms. They would need six accumulators threaded through a shared helper, which reads worse than the duplication, and the surrounding type-wide methods already parallel each other the same way - the review noted as much in raising it. * fix(engine) #5680: the empty-scope guard moves into setRecords, so it protects the public API too Review round: LGTM once the setRecords widening note was considered. Went one step further than the note it asked for. The guard against "a RECORD scope that resolves to nothing silently becomes a full database check" lived only in the SQL layer, so an embedded caller reaching DatabaseChecker.setRecords directly still hit the widening. The review reasoned that setRecords cannot tell "named records, none usable" from "named no records" - true only because the SQL layer filtered the nulls out BEFORE calling it. It no longer does: the nulls are passed through, setRecords owns both the filtering and the refusal, and one guard now covers both entry points. A genuinely empty (or null) set still means "no scope" and is accepted. Both are asserted. Also: the document arm said "cannot be loaded, removing it", but nothing removes the record there - corruptedRecords only drives the index rebuild. The review called the wording inherited and asked for no action; it is new code here, so it now says what is true, with a note on why it diverges from the type-wide checkDocuments (which also calls a document a "vertex"). Adds the warning-cap test the review asked for: 40 bogus RIDs against maxWarnings=10 retains 10 messages and still counts 40. Not added: an execution test for RECORD ... FIX COMPRESS. The compress pass is shared, unscoped code already covered elsewhere, and routing it through the scoped enumeration exercises no new branch. * docs(engine) #5680: state the COMPRESS caveat, and pin the corrupted-record fix cost with a test Review approved with three non-blocking notes; two taken. - COMPRESS is unaffected by the RECORD scope and still compresses the whole database. It is opt-in, but it is the one clause that breaks the "naming a record bounds the cost" promise, so it now sits in the release notes beside the other two costs the scope does not bound. - Added the test the review asked for: a listed record that is GENUINELY corrupted - not merely missing, not merely chain-broken - is flagged, and under FIX every index on its bucket is dropped and rebuilt. That turns the "RECORD bounds the check, not necessarily the fix" paragraph into an executable assertion, so a future change cannot quietly make a scoped repair either cheaper or more destructive than documented. Mutation-checked: dropping addCorrupted from the scoped arm fails it, and the injected corruption is the intended shape (buffer truncated to 8 bytes against the 25-byte vertex prefix), distinct from the missing-RID path. Not taken: moving the RECORD-plus-TYPE/BUCKET rejection from check() into the setters. setTypes and setRecords can be called in either order, so a setter-level guard would fire or not depending on call order; check() is the only place that sees the whole configuration. The review called the current placement acceptable. * fix(engine) #5680: a dropped RID is reported, the no-type step is named, and a comment stops overselling Review round: approve, all notes minor. Three taken. - The "Exception, not Throwable" comment claimed more protection than the code gives. It guards the LOOKUP, but the shared per-record consumer still catches Throwable around the connectivity check itself - matching the type-wide path, which is why it stays. The comment now says exactly what is and is not covered rather than implying an Error can never be recorded as corruption. - setRecords refused an all-null scope but dropped a PARTIAL one silently, so a caller who mistyped one of several RIDs got a clean report for a check that skipped it. Narrowing is still allowed - unlike widening it cannot do more than asked - but it now surfaces a warning naming how many were dropped, with a test. - The no-type group advanced currentStep without ever naming the step, so a progress poller watched it go by blank. Routed through stepBegin like the document arm, which also owns the bump. Not taken: - Rejecting RECORD together with COMPRESS for symmetry with the TYPE/BUCKET rejection. The two are not the same case: RECORD plus TYPE/BUCKET has no coherent meaning, whereas "check this record, then compress the database" is perfectly meaningful - it is just not cheap. That is a documentation problem, and the release note now states it. - @tag("slow") on the 200-edge tests. Measured rather than assumed: the whole class runs in 0.53s, and CLAUDE.md's criteria are multi-second elapsed or large batches. 200 tiny transactions under a second is neither. * fix(engine) #5680: diagnose the clause conflict first, warn that COMPRESS is unscoped Review round: refinements, not blockers. Four taken. - CHECK DATABASE TYPE Hub RECORD {"@Rid": null} reported "none of them resolves to a RID", because the RIDs are resolved before check() reaches the combination guard - pointing the operator at the inner failure while the actual mistake is the clause combination. The statement now diagnoses the combination before resolving anything; check() keeps its own guard for programmatic callers. - setRecords left droppedRecords stale on its early-return path. Harmless today, since the warning is only emitted under a record scope, but the field is public-API-visible state and should not depend on call order. - COMPRESS now warns that it is not limited by the RECORD scope. The review suggested this as a middle ground between refusing the combination and staying silent, and it is a better answer than the documentation-only one: the command still does what it was asked, but an operator who named a record and expected a bounded run is told otherwise. Tested both ways, so the warning tracks the clause rather than the scope. - Recorded, not fixed: the type-wide checkDocuments adds to the warnings/corrupted sets without incrementing the corresponding totals, so a corrupt document reports different totals depending on which path found it. The scoped arm here is the correct one; aligning the type-wide path is a behaviour change to a command this issue does not otherwise touch. Agreed with the review that the duplicated catch blocks read better than threading six accumulators through a shared helper; no change. * fix(engine) #5680: one owner for the conflict message, no counts a Set cannot know, bounded corrupted set Review round: nothing blocking. All four points taken. - The "cannot be combined with TYPE or BUCKET" text was written out in both the statement and the checker. The two-layer guard stays - the statement has to diagnose the clause conflict before the RIDs are resolved - but the wording now lives in one constant so the two cannot drift. - Two messages quoted a record count the Set could not know: several RID expressions that all resolve to null collapse to a single null element, so "given 3 record(s)" was never reachable and "1 of the record(s) did not resolve" under-reported. Rather than plumb the original count through, both messages stop quoting a number, which is accurate whatever the input. - checkScopedDocuments grew corruptedRecords without a bound while every other path honours maxCorrupted/maxWarnings. Bounded the same way, with the total still counting every occurrence. - Documented that the edge sweep a rebuild needs runs once per distinct vertex TYPE named, not once per run: ten vertices of one type cost one sweep, one vertex of each of three types cost three. (cherry picked from commit 56b47f4)
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
1 participant
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.
Bumps gson from 2.8.7 to 2.8.8.
Release notes
Sourced from gson's releases.
Changelog
Sourced from gson's changelog.
Commits
b41030d[maven-release-plugin] prepare release gson-parent-2.8.881f25c8Merge pull request #1936 from google/dependabot/maven/org.apache.maven.scm-ma...a7404e8Merge pull request #1935 from google/dependabot/maven/org.apache.maven.scm-ma...205df01Bump maven-scm-provider-gitexe from 1.11.2 to 1.11.3f98dabdBump maven-scm-api from 1.11.2 to 1.11.39edaeb3Merge pull request #1909 from HiFromAjay/aj01ab13fRemove unused imports [build(deps): bump docker/setup-qemu-action from 3.2.0 to 3.3.0 #1909, #1908]789818dMerge pull request #1930 from christofferqa/keep_typetokendf94ccdMerge pull request #1925 from google/dependabot/maven/org.apache.maven.plugin...80feb23Merge pull request #1926 from google/dependabot/maven/com.github.wvengen-prog...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)