Bump LangChain4j to 1.16.1-TB1, which adds frequencyPenalty and
presencePenalty support to the langchain4j-google-genai integration,
and pass both parameters through for Google Gemini and Google Vertex AI
Gemini models.
The upgrade changed which versions the dependency tree requests:
- drop threetenbp pin: transitives now converge on 1.6.8 without it
- lower checker-qual to 3.42.0: the highest version any transitive requests
- raise error_prone_annotations to 2.43.0: the old pin silently downgraded
dependencies requesting 2.41.0 and 2.43.0
Upgrade LangChain4j to 1.15.1-TB1 and migrate GitHub Models to the
official OpenAI integration (OpenAiOfficialChatModel), enabling JSON
Schema (strict) structured output for GitHub Models and exposing JSON
Schema as a response format for Anthropic and Amazon Bedrock.
- Rename model capability flags to supportsSchemalessJsonOutput() and
supportsJsonSchemaOutput(), declared explicitly per provider
- Push response-format capability checks into TbResponseFormat and
simplify response-format handling in TbAiNode
- Remove obsolete manual JSON escaping for GitHub Models, which now
double-escaped requests under the official OpenAI SDK
- Drop the now-obsolete opennlp-tools version pin (the upgraded
LangChain4j fork ships opennlp-tools >= 2.5.9)
- Update the AI rule node UI to offer response formats per provider,
refresh available model lists, and migrate toggle options to @if
- Expand configurer tests to verify per-provider model configuration
Netty 4.1.133.Final introduced a regression in MqttDecoder while fixing
CVE-2026-44248: when multiple MQTT packets are present in the same
cumulation buffer, the per-message size check used the total buffer size
instead of the current packet's declared remaining length. Valid in-limit
packets get rejected with TooLongFrameException("message length exceeds
65536: <small number>"). Fixed upstream by netty/netty#16787 and ported
to 4.1 as netty/netty@30f8f284db, released in 4.1.134.Final.
Spring Boot 3.5.14 ships an ImportsContextCustomizer change that
double-registers legacy @SpyBean fields, causing "Duplicate spy definition"
failures during ApplicationContext load in tests that mix @SpyBean and
@MockitoSpyBean across the test class hierarchy. Pin the test artifacts
to 3.5.13 until 3.5.15+ is released with a fix; runtime stays on 3.5.14
so the CVE fixes remain in effect.
- Group tomcat, commons-lang3 version properties under spring-boot.version
- Drop thymeleaf override (PE-only dependency, not present in CE)
- Drop lz4 plumbing: kafka-clients 3.9.2 and cassandra-all 5.0.7 now transitively ship at.yawk.lz4:lz4-java, making the Dec 2025 CVE hack obsolete
Root pom.xml wired <skipAssembly>${pkg.skip.zip}</skipAssembly> at the
plugin-level <configuration> of maven-assembly-plugin inside the
always-active `packaging` profile's <pluginManagement>. Maven merges
plugin-level <configuration> into every execution of that plugin, so
-Dpkg.skip.zip=true (and the -Dpkg.skip=true alias that activates it)
suppressed any maven-assembly-plugin execution across the reactor -
not only the intended Windows ZIP execution.
In CE lts-4.2/4.3 this is latent (no CE module declares a non-ZIP
assembly execution), but it breaks downstream forks that do. PE's
rule-node-twilio-sms, for instance, declares a custom make-assembly
execution producing the classified -rule-node.jar consumed by
application's copy-pe-rule-nodes step; under -Dpkg.skip.zip=true that
assembly silently became a no-op and the downstream build failed to
resolve the classified artifact.
tools/pom.xml already sidesteps this via `combine.self="override"` on
its own <pluginManagement> - earlier evidence that the placement was
fragile.
Move <skipAssembly> into the `assembly` execution's own <configuration>
so it scopes only to the Windows ZIP execution.
Verified via mvn help:effective-pom on application/: with the fix,
<skipAssembly>true</skipAssembly> no longer appears at plugin-level
<configuration>, only inside the `assembly` <execution>.
Build hygiene for developers who rebuild lts-4.2 frequently: cleans the
pom.xml sources that generate noise without any code change.
- Pin maven-clean-plugin to 3.5.0 (latest stable) via a
<maven-clean-plugin.version> property, matching the convention already
used for surefire/install/deploy/jar plugins. Removes 55 "version is
missing" warnings plus the cascading "Some problems were encountered
while building the effective model" messages for every child module.
- Extend license-maven-plugin excludes for files that never carry a
license header: **/lombok.config, **/eslint.config.mjs,
**/config.monitoring, **/valkey-certs/**, **/data/certs/**, **/*.otf.
Directory-scoped patterns are used instead of broad extension globs
(**/*.crt, **/*.key, **/*.pem) so a stray cert dropped outside these
directories still raises a warning.
- Exclude sjk-jfr5 / sjk-jfr6 / sjk-nps transitive deps from cassandra-all
in tools/pom.xml. Their published POMs declare system-scope deps against
unresolved ${jmc5.path}, ${jmc6.path}, ${visualvm.path} properties,
producing 7 ERROR-level lines on every build. No ThingsBoard code imports
sjk, jmc, or netbeans profiler classes.
Net impact: 1040 -> 843 WARNING lines, 7 -> 0 ERROR lines. Build still
green. Full categorization of remaining warnings and Tier 2/3 migration
plan is tracked in issue #15481.
Changelog review (v1.40..v1.48): no breaking changes to the slack-api-client
APIs used in this codebase. The only breaking changes in v1.45.0 were in
slack-app-backend (servlet classes) and slack-api-bolt-aws-lambda-s3-storage
(AWS SDK v1→v2), neither of which we depend on. Transitive deps (okhttp,
gson, okio) are unchanged.
Verified by compiling monitoring + application against 1.48.0 and running
the monitoring unit tests plus the application Notification/Slack test
suites (15 + 54 tests, all pass).
Remove <pkg.skip.bootjar>false</pkg.skip.bootjar> from all child
module <properties> blocks. The root POM already defaults it to false,
and child declarations block the skip-pkg profile override, so
-Dpkg.skip=true was never actually skipping spring-boot:repackage.
Also remove the unused surefire.version property (superseded by
maven-surefire-plugin.version).
Introduces four independent flags to skip individual packaging artifacts:
-Dpkg.skip.bootjar=true skip spring-boot repackage (*-boot.jar)
-Dpkg.skip.deb=true skip Gradle buildDeb + Maven attach-artifact
-Dpkg.skip.rpm=true skip Gradle buildRpm
-Dpkg.skip.zip=true skip maven-assembly-plugin Windows ZIP
Adds -Dpkg.skip=true as a single convenience flag that sets all four
at once. msa/pom.xml mirrors the skip-pkg profile to override its own
<pkg.deb.phase>package</pkg.deb.phase> property (child POM properties
have higher priority than parent profile properties in Maven).
msa/* docker modules used ${basedir}/../.. (non-canonical) for main.dir.
maven-enforcer-plugin 3.5.0's osIndependentNameMatch() compares
file.toURI() vs file.getCanonicalFile().toURI() — these differ when the
path contains '..', causing RequireFilesExist to report false-negative.
Fix: replace ${basedir}/../.. with ${maven.multiModuleProjectDirectory}.
When Maven runs with -T N, all modules using the packaging profile invoke
gradle-maven-plugin against the same gradleProjectDirectory
(packaging/java or packaging/js), causing them to share and contend on
the same .gradle/ project cache directory simultaneously.
Two fixes:
- Pass --project-cache-dir pointing to each module's own target/.gradle,
fully isolating parallel Gradle invocations from each other.
- Add maven-clean-plugin filesets to remove packaging/java/.gradle and
packaging/js/.gradle on mvn clean. Gradle always writes project-level
metadata to the project directory regardless of --project-cache-dir,
so these would otherwise accumulate on CI agents with persistent home
directories.
Root pluginManagement and netty-mqtt hardcoded version 3.1.1 while
the jar-plugin.version property (used by dao and others) was set to
3.4.0, causing build failures due to incompatible commons-io dependency.
Replace both hardcoded 3.1.1 occurrences with ${jar-plugin.version}
so all modules consistently use the version defined in one place.
Fixes#15037
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
TBEL 1.2.9 fixes two issues that caused TBEL scripts to fail or produce
incorrect results when executed multiple times:
1. Thread-safety: OptimizerFactory.defaultOptimizer was not volatile,
so worker threads could use DynamicOptimizer instead of the intended
SafeReflectiveOptimizer, leading to intermittent script failures.
2. MethodAccessor coercion: methods with ExecutionContext parameter
(e.g. bytesToExecutionArrayList) failed on re-execution because the
coercion fallback path did not handle ExecutionContext injection.
Also add @RepeatedTest for parseBytes_Test to verify stability.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Viacheslav Klimov
bruak
Dmytro Skarzhynets
Oleksandra Matviienko
Sergey Matvienko
Oleksii Kuripko