This repository was archived by the owner on Jul 8, 2025. It is now read-only.
Conversation
[ci] compare-results.xslt: surface runner-JAR drift warning when build SHAs differ
…f MutableCollection MutableCollection carried a schema cache (plain ConcurrentHashMap) plus the namespace-resolution/validation logic that uses it -- neither is Collection state. Splits this into two package-private classes: - Xsd11SchemaCache: the per-namespace "needs XSD 1.1?" cache, now backed by Caffeine for consistency with the codebase's other caches (no eviction policy, since the namespace set is finite and admin-controlled -- this was never a correctness concern, just a style/testability one). - Xsd11ValidationHelper: resolveXsd11SchemaForNamespace, the dynamic-discovery schema holder, parseOrValidateXmlSource, validateWithXsd11Schema, and the Xsd11LexicalHandlerForwarder record -- store-time XSD 1.1 validation, not Collection bookkeeping. MutableCollection keeps only its public clearXsd11SchemaByNamespaceCache() facade (GrammarTooling.java's external call site) and a single delegating call from storeXmlDocument(); 9 imports that only the moved code needed are dropped. Behavior-preserving: all 63 tests across the validation/XSD11 suite pass unchanged. Addresses dizzzz's review comments on #6530/#6551.
…reated edit 4e949b4 dropped xsi:type="dcterms:W3CDTF" from the dcterms:created annotation in 5 sibling schema files and correctly bumped @Version on 4 of them (collection.xconf.xsd, cxan.xsd, exist.xsd, repo.xsd) -- this one was missed, leaving expath-pkg.xsd's content changed but @Version still 1.1.0. CI's schema governance check (ci-schema-checks.yml, added in PR-A) catches exactly this. Bumps to 1.1.1, a documentation/non-semantic patch per schema/README.md's policy, matching the sibling files' bumps. Verified locally against the real merge-base with upstream/develop: mvn -N xml:transform@schema-governance passes, SchemaVersionSyncTest passes unaffected (expath-pkg.xsd isn't one of the 5 SchemaVersion.java-tracked schemas).
…nical at build time Add a Maven exec plugin execution that transforms the canonical exist-distribution conf.xml through module-specific XSLT strip-sheets, writing per-module fixture conf.xml and controller-config.xml files into src/test/resources-filtered at process-test-resources time. Eliminates ~35 hand-maintained fixture copies that drift from canonical on every schema edit.
…o URN imports Register the repo-root schema/catalog.xml in the Maven xml-maven-plugin catalog chain so XSD-against-XSD validation resolves locally without network access. Migrate all 35 XSLT strip-sheets from bare http:// imports to URN-mapped imports via the catalog. Document the new-native-schema checklist and fix the profile location note in the README.
… stylesheets conf-fixture.xsl and controller-config-fixture.xsl are new eXist-db-authored XSLT codegen tooling, not modifications of Adam Retter's original BSD-3 conf.xml/controller-config.xml. They fell outside the module's existing conf.xml/log4j2.xml excludes and so wrongly inherited the module-wide BSD-3 header. Excludes them from the BSD-3 licenseSet and adds a second licenseSet applying eXist-db's default LGPL-21 header to just these two files instead. Addresses review discussion between dizzzz, adamretter, and reinhapa on #6551.
exist-core-jmh and exist-indexes-jmh have no continuous tracking: numbers
only exist as one-off local runs pasted into PR descriptions. Port the
gh-pages benchmark-dashboard approach from BetaMasaheft/betmas-e2e
(benchmark-action/github-action-benchmark) so JMH results accumulate as a
time series instead.
Adds .github/workflows/ci-benchmarks.yml: builds and runs both JMH modules
weekly (and on manual dispatch) with reduced iteration counts suitable for
a shared runner (-wi 2 -i 5 -f 1 - a trend signal, not a publishable
number), then pushes each module's JSON output to gh-pages under
dev/bench/core and dev/bench/indexes via the jmh tool adapter. Report-only:
alerts on >150% regressions via commit comment, never fails the run.
Publish steps are guarded to github.repository == 'eXist-db/exist' so a
fork running this workflow doesn't attempt to push to someone else's
gh-pages. GitHub Pages itself still needs to be enabled in this repo's
Settings once the workflow has run at least once and created the gh-pages
branch.
Adds a "Continuous tracking" section to exist-indexes-jmh/README.md and
drops the roadmap item ("CI nightly job posting numbers to a tracking
issue") this supersedes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Refs #6387 PR #6318 (util:expand Lucene term-rewrite cache, closes #5738) originally included two perf-ratio assertions in surefire (UtilExpandHighlightingPerformanceTest); a later commit on that PR removed them per review - hard perf thresholds are flaky on shared CI runners, and the index-extension reactor had no benchmark module yet. #6387 tracked migrating them to JMH. exist-core-jmh already depends on exist-index-lucene and hosts other Lucene benchmarks (LucenePhraseQueryBenchmark, ReindexDeleteStrategyBenchmark), so this adds UtilExpandHighlightingBenchmark there rather than standing up the separate extensions/indexes/ reactor #6387 originally proposed - that gap it assumed no longer exists. Mirrors ArrowOperatorBenchmark's arrow*/direct* pairing: each shape has a *HighlightingOff / *HighlightingOn pair over an identical corpus and compiled query, so the dashboard shows both series and their trend rather than asserting a single ratio threshold. - expandSingleHit{Off,On}: single hit via subsequence($hits, 1, 1) - expandBatchWildcard{Off,On}: util:expand($hits) over ~half of a 5,000-entry corpus matched by a lemma:a* wildcard - the path the per-Query term-rewrite cache targets Each benchmark still asserts the expected hit count (a "fast but wrong" guard, not a performance threshold). Smoke-tested locally (-wi 1 -i 1 -f 1 -w 3s -r 3s): expandBatchWildcardHighlightingOff ~41ms/op vs HighlightingOn ~228ms/op, consistent with PR #6318's measured ~4-5x. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bumps the maven-plugins-tools group with 1 update: [org.codehaus.mojo:flatten-maven-plugin](https://github.com/mojohaus/flatten-maven-plugin). Updates `org.codehaus.mojo:flatten-maven-plugin` from 1.7.3 to 1.8.0 - [Release notes](https://github.com/mojohaus/flatten-maven-plugin/releases) - [Commits](mojohaus/flatten-maven-plugin@1.7.3...1.8.0) --- updated-dependencies: - dependency-name: org.codehaus.mojo:flatten-maven-plugin dependency-version: 1.8.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: maven-plugins-tools ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [com.fifesoft:rsyntaxtextarea](https://github.com/bobbylight/rsyntaxtextarea) from 4.0.0 to 4.0.1. - [Release notes](https://github.com/bobbylight/rsyntaxtextarea/releases) - [Commits](bobbylight/RSyntaxTextArea@4.0.0...4.0.1) --- updated-dependencies: - dependency-name: com.fifesoft:rsyntaxtextarea dependency-version: 4.0.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…rsyntaxtextarea-4.0.1 Bump com.fifesoft:rsyntaxtextarea from 4.0.0 to 4.0.1
…-tools-9ab7b2c2d6 Bump org.codehaus.mojo:flatten-maven-plugin from 1.7.3 to 1.8.0 in the maven-plugins-tools group
Bumps [com.microsoft.onnxruntime:onnxruntime](https://github.com/microsoft/onnxruntime) from 1.27.0 to 1.28.0. - [Release notes](https://github.com/microsoft/onnxruntime/releases) - [Changelog](https://github.com/microsoft/onnxruntime/blob/main/docs/ReleaseManagement.md) - [Commits](microsoft/onnxruntime@v1.27.0...v1.28.0) --- updated-dependencies: - dependency-name: com.microsoft.onnxruntime:onnxruntime dependency-version: 1.28.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
….onnxruntime-onnxruntime-1.28.0 Bump com.microsoft.onnxruntime:onnxruntime from 1.27.0 to 1.28.0
…sion [feature] restore izpack compression format to xz
Bumps com.oracle.database.jdbc:ojdbc11 from 23.26.2.0.0 to 23.26.3.0.0. --- updated-dependencies: - dependency-name: com.oracle.database.jdbc:ojdbc11 dependency-version: 23.26.3.0.0 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…tabase.jdbc-ojdbc11-23.26.3.0.0 Bump com.oracle.database.jdbc:ojdbc11 from 23.26.2.0.0 to 23.26.3.0.0
Bumps [org.jspecify:jspecify](https://github.com/jspecify/jspecify) from 1.0.0 to 1.0.1. - [Release notes](https://github.com/jspecify/jspecify/releases) - [Commits](jspecify/jspecify@v1.0.0...v1.0.1) --- updated-dependencies: - dependency-name: org.jspecify:jspecify dependency-version: 1.0.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…jspecify-1.0.1
Bumps the apache-commons group with 1 update: [commons-codec:commons-codec](https://github.com/apache/commons-codec). Updates `commons-codec:commons-codec` from 1.22.0 to 1.22.1 - [Changelog](https://github.com/apache/commons-codec/blob/master/RELEASE-NOTES.txt) - [Commits](apache/commons-codec@rel/commons-codec-1.22.0...rel/commons-codec-1.22.1) --- updated-dependencies: - dependency-name: commons-codec:commons-codec dependency-version: 1.22.1 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: apache-commons ... Signed-off-by: dependabot[bot] <support@github.com>
…s-96c78cca71 Bump commons-codec:commons-codec from 1.22.0 to 1.22.1 in the apache-commons group
Publish JMH benchmark results to a gh-pages dashboard
Bumps the junit4-test-support group with 3 updates: [org.xmlunit:xmlunit-core](https://github.com/xmlunit/xmlunit), [org.xmlunit:xmlunit-matchers](https://github.com/xmlunit/xmlunit) and [org.xmlunit:xmlunit-legacy](https://github.com/xmlunit/xmlunit). Updates `org.xmlunit:xmlunit-core` from 2.12.0 to 2.13.0 - [Release notes](https://github.com/xmlunit/xmlunit/releases) - [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md) - [Commits](xmlunit/xmlunit@v2.12.0...v2.13.0) Updates `org.xmlunit:xmlunit-matchers` from 2.12.0 to 2.13.0 - [Release notes](https://github.com/xmlunit/xmlunit/releases) - [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md) - [Commits](xmlunit/xmlunit@v2.12.0...v2.13.0) Updates `org.xmlunit:xmlunit-legacy` from 2.12.0 to 2.13.0 - [Release notes](https://github.com/xmlunit/xmlunit/releases) - [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md) - [Commits](xmlunit/xmlunit@v2.12.0...v2.13.0) Updates `org.xmlunit:xmlunit-matchers` from 2.12.0 to 2.13.0 - [Release notes](https://github.com/xmlunit/xmlunit/releases) - [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md) - [Commits](xmlunit/xmlunit@v2.12.0...v2.13.0) Updates `org.xmlunit:xmlunit-legacy` from 2.12.0 to 2.13.0 - [Release notes](https://github.com/xmlunit/xmlunit/releases) - [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md) - [Commits](xmlunit/xmlunit@v2.12.0...v2.13.0) --- updated-dependencies: - dependency-name: org.xmlunit:xmlunit-core dependency-version: 2.13.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: junit4-test-support - dependency-name: org.xmlunit:xmlunit-matchers dependency-version: 2.13.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: junit4-test-support - dependency-name: org.xmlunit:xmlunit-legacy dependency-version: 2.13.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: junit4-test-support - dependency-name: org.xmlunit:xmlunit-matchers dependency-version: 2.13.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: junit4-test-support - dependency-name: org.xmlunit:xmlunit-legacy dependency-version: 2.13.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: junit4-test-support ... Signed-off-by: dependabot[bot] <support@github.com>
…/consolidation Drop an import left dangling by the nested-class extraction, collapse CachingResponseWrapper's double header-name switch now that BufferedHeader exposes name() directly, and deduplicate the consolidated pipeline test's per-scenario chmod/teardown/assertion boilerplate into shared helpers. HttpResponseResult now carries response headers so three tests no longer need to hand-roll HttpClient.send() just to read them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hoist scenario fixture fields to the class top and drop unnecessary fully-qualified names so FieldDeclarationsShouldBeAtStartOfClass and UnnecessaryFullyQualifiedName pass after the rebase. Co-authored-by: Cursor <cursoragent@cursor.com>
…of e.g. SQL update with an Oracle database.
Bumps the maven-plugins-tools group with 4 updates: [org.codehaus.mojo:xml-maven-plugin](https://github.com/mojohaus/xml-maven-plugin), [org.codehaus.mojo:versions-maven-plugin](https://github.com/mojohaus/versions), [org.codehaus.mojo:exec-maven-plugin](https://github.com/mojohaus/exec-maven-plugin) and [org.codehaus.mojo:build-helper-maven-plugin](https://github.com/mojohaus/build-helper-maven-plugin). Updates `org.codehaus.mojo:xml-maven-plugin` from 1.2.1 to 1.2.2 - [Release notes](https://github.com/mojohaus/xml-maven-plugin/releases) - [Commits](mojohaus/xml-maven-plugin@xml-maven-plugin-1.2.1...xml-maven-plugin-1.2.2) Updates `org.codehaus.mojo:versions-maven-plugin` from 2.21.0 to 2.22.0 - [Release notes](https://github.com/mojohaus/versions/releases) - [Changelog](https://github.com/mojohaus/versions/blob/master/ReleaseNotes.md) - [Commits](mojohaus/versions@2.21.0...2.22.0) Updates `org.codehaus.mojo:exec-maven-plugin` from 3.6.3 to 3.6.4 - [Release notes](https://github.com/mojohaus/exec-maven-plugin/releases) - [Commits](mojohaus/exec-maven-plugin@3.6.3...3.6.4) Updates `org.codehaus.mojo:build-helper-maven-plugin` from 3.6.1 to 3.6.2 - [Release notes](https://github.com/mojohaus/build-helper-maven-plugin/releases) - [Commits](mojohaus/build-helper-maven-plugin@3.6.1...3.6.2) --- updated-dependencies: - dependency-name: org.codehaus.mojo:xml-maven-plugin dependency-version: 1.2.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: maven-plugins-tools - dependency-name: org.codehaus.mojo:versions-maven-plugin dependency-version: 2.22.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: maven-plugins-tools - dependency-name: org.codehaus.mojo:exec-maven-plugin dependency-version: 3.6.4 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: maven-plugins-tools - dependency-name: org.codehaus.mojo:build-helper-maven-plugin dependency-version: 3.6.2 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: maven-plugins-tools ... Signed-off-by: dependabot[bot] <support@github.com>
inspect:inspect-module dropped everything from the first '@' in an xqdoc comment to the end of that description, with no error raised -- the truncated text came back as if complete. "Selects taxonomy[@type = "reign"] from the source." was returned as "Selects taxonomy[". Every consumer of xqdoc descriptions is affected, because inspect:inspect-module is the ecosystem's only introspection entry point: published function documentation, editor hover text and autocomplete descriptions all degrade at once, and because it fails silently nobody notices until a sentence reads oddly. The lexer's CHARS rule excludes '@', so prose can never contain one. What follows depends on the next character: '@' plus alphanumerics lexes as TAG, and the parser's ( TAG ) => taggedContents predicate then opens a new xqdoc tag mid-sentence, filing the rest of the paragraph under a tag nobody reads; a bare '@' emits AT, which no parser rule accepted at all. A real xqdoc tag only ever appears at the start of a comment line, immediately after the leading " : ". The contents rule now tracks that position and treats '@' anywhere else as ordinary text: a guarded alternative appends a mid-prose TAG, and a new alternative appends a bare AT. A line-start TAG still matches no alternative, so contents ends there and the outer predicate fires exactly as before. Fixing this in the parser rather than the lexer is deliberate. Making TAG match only at line start needs either mutable lexer state or '@' folded into CHARS, and the latter creates a genuine CHARS/TAG ambiguity in a single-DFA ANTLR 2 lexer. The parser already has the information -- it can see that only whitespace has been consumed since the line's ':' -- so no state has to be invented, and tokenization is unchanged, which keeps @param/@return recognition from regressing through a lexer path that was not anticipated. ANTLR reports no new class of warning. The existing "nondeterminism ... between alt N and exit branch of block" warnings on this closure go from three to five only because the closure gained two alternatives; the "Syntactic predicate ignored" warning belongs to the untouched SIMPLE_COLON lexer rule. InspectModuleTest.withAtSignInline was already present and @ignore'd against this issue; it is now enabled. Added alongside it: an '@' mid-description, a bare '@' with an email address and a trailing '@', and a function whose @PARAM and @return values themselves contain '@' -- the last being the regression case, since it pins that tags are still parsed as tags. Four of the seven fail without this change. The '%' half of the issue is already resolved on develop: the existing onAnnotatedFunction test inspects a %public %x:path(...) function and passes unchanged. Closes #1386 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-tools-42c7247808
This fixes an issue when you'd create a user in the post-install phase if you install an app by
placing the xar in the autodeploy directory. The `exist` broker is created _after_ the startup
triggers are done.
Why
.save() (no broker) and .save(broker) are two different code paths, and only one of them is safe to
call during startup:
- .save() -> Configurator.save(instance, uri) → calls the static BrokerPool.getInstance(), which
looks up a named registry entry ("exist") that only gets populated at the very end of
BrokerPool._initialize() — after AutoDeploymentTrigger (a StartupTrigger) has already run. Called
from inside a startup trigger, this fails unconditionally, every time.
- .save(broker) -> passes the broker to Configurator.save(broker, instance, uri), which just does
broker.getCollection(...) — no registry lookup, works fine at any point in startup.
updateAccount/updateGroup already call getDatabase().getActiveBroker() one line above (for the
permission check) - a perfectly valid broker, available even mid-startup — and then throwing it away
and calling the no-broker .save() anyway. addAccount/addGroup (the creation-side twins) already got
this right. But `update` did not.
Fixes #1610
…ouble-escaping [bugfix] XQSuite: don't re-serialize already-serialized failure values
[test] Extract nested classes and consolidate test suite
When omit-xml-declaration is "no" and the document has no persisted XML Declaration, XMLWriter generates one with version "1.0" and encoding "UTF-8" (DEFAULT_XML_VERSION / DEFAULT_XML_ENCODING). Mention these defaults, and that the version, encoding and standalone serialization parameters take precedence, in conf.xsd and conf.xml. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASiMAehNpncHLvKSS2oDnt
[bugfix] Handle SQLexception gracefully for rs.getMetaData()
[fix] remove omit-original-xml-declaration flag
The mac-codesign-lz4-native exec execution in exist-distribution/pom.xml hardcoded the lz4-java version as "1.11.0", while exist-core/pom.xml's dependency version was independently bumped by Dependabot to 1.11.2. The codesign script then looked for a nonexistent lz4-java-1.11.0.jar, failing the Build macOS DMG job for eXist-7.0.0-beta4: https://github.com/eXist-db/exist/actions/runs/34980577287/job/104424041837 Introduce a shared lz4-java.version property in exist-parent/pom.xml (mirroring the existing jansi.version pattern) so exist-core's dependency and exist-distribution's codesign script argument stay in sync, including on future Dependabot bumps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
[bugfix] Fix macOS DMG codesign broken by lz4-java version drift
Bumps the actions group with 1 update: [azure/login](https://github.com/azure/login). Updates `azure/login` from 3.0.2 to 3.1.0 - [Release notes](https://github.com/azure/login/releases) - [Commits](Azure/login@7ddb5af...a641126) --- updated-dependencies: - dependency-name: azure/login dependency-version: 3.1.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: actions ... Signed-off-by: dependabot[bot] <support@github.com>
…ons-a32b23bf08
Raised in review: a line of prose can legitimately open with an '@', and the previous commit's line-start rule was not enough on its own to tell "@home is where the heart is." from "@SInCE 1.0". The consequence was worse than the line simply vanishing from the description. Every tag that is not @PARAM or @return goes into XQDocHelper's generic meta map, and InspectFunctionHelper turns each of those into an element named after the tag: builder.startElement(new QName(meta.getKey(), XMLConstants.NULL_NS_URI), null); So a prose line opening "@home ..." was removed from the description and re-emitted as <home>, and "@2024 ..." produced an element named 2024 -- not a valid XML NCName -- with no error raised anywhere. Tag recognition now requires both the line-start position and membership in the set of tags the xqDoc specification defines. Everything else at line start is prose, which is what an author writing an email address or a year at the start of a line intends. Measured before choosing a closed set: across all 304 XQuery source files in this repository, the only line-start xqdoc tags in use are @see (94), @return (45), @author (24), @PARAM (21), and one @returns typo. Nothing here depends on an open tag set. BEHAVIOR CHANGE worth noting for anyone relying on it: a custom tag such as @mycompany no longer becomes queryable metadata on inspect:inspect-module -- it stays in the description as prose. Nothing in this repository uses one. The single @returns typo now surfaces in the description, where its author can see it, rather than as a <returns> element nothing reads. As a side effect the ANTLR nondeterminism warnings on this closure drop from five back to three, matching the pre-change baseline exactly: the semantic predicate now disambiguates the TAG and AT alternatives that previously conflicted with the loop exit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ed schema The previous commit's tag set was assembled from memory and was wrong: it included @example and @library, neither of which is an xqDoc tag. "library" appears in extensions/xqdoc/xqdoc-1.0.xsd only as a module-type enumeration value (library vs main), not as a comment directive. Both authorities agree on exactly eight tags -- @author, @Version, @PARAM, @return, @error, @deprecated, @see, @SInCE: - the xqdoc-1.0.xsd shipped in this repository, whose "comment" complexType is a closed xsd:sequence of exactly those eight elements plus "description" (the xsd:any inside mixed-text permits embedded HTML within a value, not additional directives); - the specification at https://xqdoc.org/xqdoc_comments_doc.html, which lists the same eight. That the schema's sequence is closed also answers the open question left by the previous commit. A custom tag such as @mycompany was never representable in xqDoc: it could not validate against xqdoc-1.0.xsd. So restricting recognition to these eight is not a behavior regression for any conforming document -- it brings the parser into line with the format it implements. Note the specification does not explicitly require a tag to stand at the start of a comment line; its examples all show one there, after the leading " : ". The line-start rule this parser applies is a reading of those examples rather than a stated requirement. What the specification does state -- "the beginning text (up to the first tag) is assumed to be description text" -- is why mis-recognizing a word as a tag truncates the description, and why getting the set right matters. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bumps the maven-plugins-apache group with 2 updates: [org.apache.maven.plugins:maven-install-plugin](https://github.com/apache/maven-install-plugin) and [org.apache.maven.plugins:maven-deploy-plugin](https://github.com/apache/maven-deploy-plugin). Updates `org.apache.maven.plugins:maven-install-plugin` from 3.1.4 to 3.2.0 - [Release notes](https://github.com/apache/maven-install-plugin/releases) - [Commits](apache/maven-install-plugin@maven-install-plugin-3.1.4...maven-install-plugin-3.2.0) Updates `org.apache.maven.plugins:maven-deploy-plugin` from 3.1.4 to 3.2.0 - [Release notes](https://github.com/apache/maven-deploy-plugin/releases) - [Commits](apache/maven-deploy-plugin@maven-deploy-plugin-3.1.4...maven-deploy-plugin-3.2.0) --- updated-dependencies: - dependency-name: org.apache.maven.plugins:maven-install-plugin dependency-version: 3.2.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: maven-plugins-apache - dependency-name: org.apache.maven.plugins:maven-deploy-plugin dependency-version: 3.2.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: maven-plugins-apache ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [at.yawk.lz4:lz4-java](https://github.com/yawkat/lz4-java) from 1.11.2 to 1.11.3. - [Release notes](https://github.com/yawkat/lz4-java/releases) - [Changelog](https://github.com/yawkat/lz4-java/blob/main/CHANGES.md) - [Commits](yawkat/lz4-java@v1.11.2...v1.11.3) --- updated-dependencies: - dependency-name: at.yawk.lz4:lz4-java dependency-version: 1.11.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…z4-java-1.11.3
…-apache-1d5ab2855f
[bugfix] Pass a broker when creating new users
Bumps [net.bytebuddy:byte-buddy](https://github.com/raphw/byte-buddy) from 1.18.13 to 1.18.14. - [Release notes](https://github.com/raphw/byte-buddy/releases) - [Changelog](https://github.com/raphw/byte-buddy/blob/master/release-notes.md) - [Commits](raphw/byte-buddy@byte-buddy-1.18.13...byte-buddy-1.18.14) --- updated-dependencies: - dependency-name: net.bytebuddy:byte-buddy dependency-version: 1.18.14 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [com.microsoft.onnxruntime:onnxruntime](https://github.com/microsoft/onnxruntime) from 1.29.0 to 1.30.0. - [Release notes](https://github.com/microsoft/onnxruntime/releases) - [Changelog](https://github.com/microsoft/onnxruntime/blob/main/docs/ReleaseNotesWorkflow.md) - [Commits](microsoft/onnxruntime@v1.29.0...v1.30.0) --- updated-dependencies: - dependency-name: com.microsoft.onnxruntime:onnxruntime dependency-version: 1.30.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…-byte-buddy-1.18.14 Bump net.bytebuddy:byte-buddy from 1.18.13 to 1.18.14
….onnxruntime-onnxruntime-1.30.0 Bump com.microsoft.onnxruntime:onnxruntime from 1.29.0 to 1.30.0
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )