Skip to content

Bump the all-maven-dependencies group across 2 directories with 1 update - #752

Merged
mofterdinger merged 1 commit into
mainfrom
dependabot/maven/all-maven-dependencies-e87fded1d0
Nov 12, 2026
Merged

Bump the all-maven-dependencies group across 2 directories with 1 update#752
mofterdinger merged 1 commit into
mainfrom
dependabot/maven/all-maven-dependencies-e87fded1d0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Nov 12, 2026

Copy link
Copy Markdown
Contributor

Bumps the all-maven-dependencies group with 1 update in the / directory: com.sap.cloud.security:java-bom.
Bumps the all-maven-dependencies group with 1 update in the /srv directory: com.sap.cloud.security:java-bom.

Updates com.sap.cloud.security:java-bom from 4.1.2 to 4.3.1

Release notes

Sourced from com.sap.cloud.security:java-bom's releases.

4.3.1

  • Retry token, token-key, and OIDC-discovery requests on network errors (token-client, token-client-spring, token-client-spring-3)
    • The retry feature previously only acted on configured HTTP status codes. A network error (connection reset, read timeout, TLS handshake error) was rethrown immediately, so transient network failures during access-token, JWKS, or OIDC-discovery retrieval were never retried — even with retry enabled and maxRetryAttempts configured. In the plain client this surfaced as Error retrieving token keys: null during short identity-service blips.
    • Affected classes now retry on network errors as well, bounded by the existing maxRetryAttempts and retryDelayTime:
      • DefaultOAuth2TokenService, DefaultOAuth2TokenKeyService, DefaultOidcConfigurationService (retry on IOException)
      • XsuaaOAuth2TokenService, SpringOAuth2TokenKeyService, SpringOidcConfigurationService (retry on ResourceAccessException)
    • The Spring variants additionally route retryable HTTP status codes (HttpStatusCodeException) through the same retry handling, so the configured retryStatusCodes now take effect even though RestTemplate surfaces non-2xx responses as exceptions.
    • An already-decided HTTP outcome (OAuth2ServiceException) is still never retried.
    • This aligns the behavior with the documented retry feature, which states that requests failing due to "network issues, such as timeouts or connection errors" are retried.

4.3.0

  • Split java-security into a new java-security-core module for Jakarta-free token validation
    • The token model (com.sap.cloud.security.token), the JWT validation packages (com.sap.cloud.security.token.validation, incl. JwtValidatorBuilder and all validators), com.sap.cloud.security.x509, and the TokenFactory ServiceLoader registration (via HybridTokenFactory) moved to java-security-core
    • java-security-core has no jakarta.servlet and no Spring dependencies, so token validation can be used from javax-based runtimes (e.g. Tomcat 9) without any Jakarta API on the classpath
    • java-security keeps the servlet-based authenticators (HybridTokenAuthenticator, IasTokenAuthenticator, XsuaaTokenAuthenticator) and the Spring security context adapter, and now depends on java-security-core
    • No API or behavior change for existing java-security consumers: all moved classes keep their fully qualified names and stay on the classpath transitively (minor release)
  • Keep the Spring Boot 3 starter's transitive Spring Framework dependencies on 6.x by overriding the parent Framework version
  • Update dependencies:
    • Spring Boot: 4.1.1 → 4.1.2
    • Spring Framework: 7.0.9 → 7.0.10
    • Spring Security: 7.1.1 → 7.1.2
    • Reactor (core & test): 3.8.7 → 3.8.8
    • Maven Surefire Plugin: 3.6.0 → 3.6.1
    • JaCoCo: 0.8.15 → 0.8.16
    • Spring Boot 3 / Spring Framework 6 / Spring Security 6 compatibility versions remain unchanged for the legacy modules

4.2.0

  • Distributed cache support for the internal token, JWKS, and OIDC discovery caches
    • The library's three internal caches previously lived only in the JVM's memory: after every restart or rolling deploy every pod re-fetched signing keys and re-issued its own tokens from XSUAA / IAS, causing cold-start latency and thundering-herd traffic against the identity services
    • New SecurityCache<String,String> SPI (java-api) behind all three caches; the in-memory Caffeine implementation remains the default, so existing applications see no behavior change
    • Two adapters ship out of the box: CaffeineSecurityCache (in-process default) and SpringCacheSecurityCache (wraps any Spring CacheManager backend such as Redis or Hazelcast); any other backend can be implemented against the SPI (copy-paste snippets in the main README)
    • Spring Boot: opt-in via sap.security.cache.distributed.enabled=true; the auto-configuration wires a SecurityCache bean from a user-supplied bean or a CacheManager cache named sap-security (configurable via sap.security.cache.distributed.cache-name) and fails fast with a clear error if no backing store is present
    • Plain Java: pass a SecurityCache to the DefaultOAuth2TokenService constructor (token cache) or JwtValidatorBuilder.withSecurityCache(...) / AbstractTokenAuthenticator.withSecurityCache(...) (JWKS + OIDC caches)
    • Cache entries are raw JSON strings and keys are namespaced (tokens:, jwks:, oidc:), so entries are safe to share across processes; token request fingerprints are SHA-256 hashed, so client secrets never appear in the key space or logs
    • Concurrent misses for the same key are collapsed into a single upstream call in all three caches (single-flight)
    • See the main README, section "2.5 Distributed Caching", for setup, bring-your-own-cache snippets, operational notes, and known limitations
  • Negative caching of stable JWKS retrieval failures
    • A /token_keys call that fails with a client error (4xx, e.g. a 404 for an unknown zone id) is now remembered for 30 seconds: repeated requests for the same invalid key fail fast with an exception instead of each triggering a new call to the identity service, so a stream of invalid tokens can no longer keep exhausting HTTP resources
    • Transient failures — server errors (5xx), timeouts, transport errors — are not negatively cached, so the next request retries immediately
    • After the 30-second window the next request retries the retrieval
  • CaffeineSecurityCache now honors per-entry TTLs
    • SecurityCache.set(key, value, ttl) durations shorter than the cache-wide default (as used by the 30-second negative cache entries) are now respected by the Caffeine adapter via Caffeine's Expiry policy; previously the per-entry TTL argument was ignored
  • Send the x-azp_app_tid request header when fetching IAS signing keys
    • When validating an IAS token, the azp_app_tid claim is now forwarded as an x-azp_app_tid header on the /token_keys request (only when the claim is present), mirroring the @sap/xssec 4.15.0 behavior
  • Update dependencies:
    • Jetty: 12.1.12 → 12.1.14
    • SLF4J API: 2.0.18 → 2.0.20
    • Mockito: 5.23.0 → 5.24.0
    • Maven Surefire Plugin: 3.5.6 → 3.6.0
    • org.json: 20260719 → 20260814

... (truncated)

Changelog

Sourced from com.sap.cloud.security:java-bom's changelog.

4.3.1

  • Retry token, token-key, and OIDC-discovery requests on network errors (token-client, token-client-spring, token-client-spring-3)
    • The retry feature previously only acted on configured HTTP status codes. A network error (connection reset, read timeout, TLS handshake error) was rethrown immediately, so transient network failures during access-token, JWKS, or OIDC-discovery retrieval were never retried — even with retry enabled and maxRetryAttempts configured. In the plain client this surfaced as Error retrieving token keys: null during short identity-service blips.
    • Affected classes now retry on network errors as well, bounded by the existing maxRetryAttempts and retryDelayTime:
      • DefaultOAuth2TokenService, DefaultOAuth2TokenKeyService, DefaultOidcConfigurationService (retry on IOException)
      • XsuaaOAuth2TokenService, SpringOAuth2TokenKeyService, SpringOidcConfigurationService (retry on ResourceAccessException)
    • The Spring variants additionally route retryable HTTP status codes (HttpStatusCodeException) through the same retry handling, so the configured retryStatusCodes now take effect even though RestTemplate surfaces non-2xx responses as exceptions.
    • An already-decided HTTP outcome (OAuth2ServiceException) is still never retried.
    • This aligns the behavior with the documented retry feature, which states that requests failing due to "network issues, such as timeouts or connection errors" are retried.

4.3.0

  • Split java-security into a new java-security-core module for Jakarta-free token validation
    • The token model (com.sap.cloud.security.token), the JWT validation packages (com.sap.cloud.security.token.validation, incl. JwtValidatorBuilder and all validators), com.sap.cloud.security.x509, and the TokenFactory ServiceLoader registration (via HybridTokenFactory) moved to java-security-core
    • java-security-core has no jakarta.servlet and no Spring dependencies, so token validation can be used from javax-based runtimes (e.g. Tomcat 9) without any Jakarta API on the classpath
    • java-security keeps the servlet-based authenticators (HybridTokenAuthenticator, IasTokenAuthenticator, XsuaaTokenAuthenticator) and the Spring security context adapter, and now depends on java-security-core
    • No API or behavior change for existing java-security consumers: all moved classes keep their fully qualified names and stay on the classpath transitively (minor release)
  • Keep the Spring Boot 3 starter's transitive Spring Framework dependencies on 6.x by overriding the parent Framework version
  • Update dependencies:
    • Spring Boot: 4.1.1 → 4.1.2
    • Spring Framework: 7.0.9 → 7.0.10
    • Spring Security: 7.1.1 → 7.1.2
    • Reactor (core & test): 3.8.7 → 3.8.8
    • Maven Surefire Plugin: 3.6.0 → 3.6.1
    • JaCoCo: 0.8.15 → 0.8.16
    • Spring Boot 3 / Spring Framework 6 / Spring Security 6 compatibility versions remain unchanged for the legacy modules

4.2.0

  • Distributed cache support for the internal token, JWKS, and OIDC discovery caches
    • The library's three internal caches previously lived only in the JVM's memory: after every restart or rolling deploy every pod re-fetched signing keys and re-issued its own tokens from XSUAA / IAS, causing cold-start latency and thundering-herd traffic against the identity services
    • New SecurityCache<String,String> SPI (java-api) behind all three caches; the in-memory Caffeine implementation remains the default, so existing applications see no behavior change
    • Two adapters ship out of the box: CaffeineSecurityCache (in-process default) and SpringCacheSecurityCache (wraps any Spring CacheManager backend such as Redis or Hazelcast); any other backend can be implemented against the SPI (copy-paste snippets in the main README)
    • Spring Boot: opt-in via sap.security.cache.distributed.enabled=true; the auto-configuration wires a SecurityCache bean from a user-supplied bean or a CacheManager cache named sap-security (configurable via sap.security.cache.distributed.cache-name) and fails fast with a clear error if no backing store is present
    • Plain Java: pass a SecurityCache to the DefaultOAuth2TokenService constructor (token cache) or JwtValidatorBuilder.withSecurityCache(...) / AbstractTokenAuthenticator.withSecurityCache(...) (JWKS + OIDC caches)
    • Cache entries are raw JSON strings and keys are namespaced (tokens:, jwks:, oidc:), so entries are safe to share across processes; token request fingerprints are SHA-256 hashed, so client secrets never appear in the key space or logs
    • Concurrent misses for the same key are collapsed into a single upstream call in all three caches (single-flight)
    • See the main README, section "2.5 Distributed Caching", for setup, bring-your-own-cache snippets, operational notes, and known limitations
  • Negative caching of stable JWKS retrieval failures
    • A /token_keys call that fails with a client error (4xx, e.g. a 404 for an unknown zone id) is now remembered for 30 seconds: repeated requests for the same invalid key fail fast with an exception instead of each triggering a new call to the identity service, so a stream of invalid tokens can no longer keep exhausting HTTP resources
    • Transient failures — server errors (5xx), timeouts, transport errors — are not negatively cached, so the next request retries immediately
    • After the 30-second window the next request retries the retrieval
  • CaffeineSecurityCache now honors per-entry TTLs
    • SecurityCache.set(key, value, ttl) durations shorter than the cache-wide default (as used by the 30-second negative cache entries) are now respected by the Caffeine adapter via Caffeine's Expiry policy; previously the per-entry TTL argument was ignored
  • Send the x-azp_app_tid request header when fetching IAS signing keys
    • When validating an IAS token, the azp_app_tid claim is now forwarded as an x-azp_app_tid header on the /token_keys request (only when the claim is present), mirroring the @sap/xssec 4.15.0 behavior
  • Update dependencies:
    • Jetty: 12.1.12 → 12.1.14
    • SLF4J API: 2.0.18 → 2.0.20

... (truncated)

Commits
  • e2bf023 fix(token-client): retry on network errors across plain + Spring clients (4.3...
  • d4212cf update maven central deployment name (#2067)
  • 85f9815 chore: prepare release 4.3.0 (#2065)
  • e67922c Build(deps): Bump the prod-deps-ver group across 1 directory with 15 updates ...
  • 8574c12 Feat/split java security core (#2032)
  • 0732e26 Build(deps-dev): Bump io.github.hakky54:logcaptor from 2.12.7 to 2.13.0 in th...
  • 1c25e8e Merge pull request #2053 from SAP/chore/dependabot-3.x-no-majors
  • eaa6bd6 Merge branch 'main' into chore/dependabot-3.x-no-majors
  • 6499a38 chore: stop Dependabot from proposing major upgrades on main-3.x
  • d44f48c Merge pull request #2051 from SAP/release-4.2.0-integration
  • Additional commits viewable in compare view

Updates com.sap.cloud.security:java-bom from 4.1.2 to 4.3.1

Release notes

Sourced from com.sap.cloud.security:java-bom's releases.

4.3.1

  • Retry token, token-key, and OIDC-discovery requests on network errors (token-client, token-client-spring, token-client-spring-3)
    • The retry feature previously only acted on configured HTTP status codes. A network error (connection reset, read timeout, TLS handshake error) was rethrown immediately, so transient network failures during access-token, JWKS, or OIDC-discovery retrieval were never retried — even with retry enabled and maxRetryAttempts configured. In the plain client this surfaced as Error retrieving token keys: null during short identity-service blips.
    • Affected classes now retry on network errors as well, bounded by the existing maxRetryAttempts and retryDelayTime:
      • DefaultOAuth2TokenService, DefaultOAuth2TokenKeyService, DefaultOidcConfigurationService (retry on IOException)
      • XsuaaOAuth2TokenService, SpringOAuth2TokenKeyService, SpringOidcConfigurationService (retry on ResourceAccessException)
    • The Spring variants additionally route retryable HTTP status codes (HttpStatusCodeException) through the same retry handling, so the configured retryStatusCodes now take effect even though RestTemplate surfaces non-2xx responses as exceptions.
    • An already-decided HTTP outcome (OAuth2ServiceException) is still never retried.
    • This aligns the behavior with the documented retry feature, which states that requests failing due to "network issues, such as timeouts or connection errors" are retried.

4.3.0

  • Split java-security into a new java-security-core module for Jakarta-free token validation
    • The token model (com.sap.cloud.security.token), the JWT validation packages (com.sap.cloud.security.token.validation, incl. JwtValidatorBuilder and all validators), com.sap.cloud.security.x509, and the TokenFactory ServiceLoader registration (via HybridTokenFactory) moved to java-security-core
    • java-security-core has no jakarta.servlet and no Spring dependencies, so token validation can be used from javax-based runtimes (e.g. Tomcat 9) without any Jakarta API on the classpath
    • java-security keeps the servlet-based authenticators (HybridTokenAuthenticator, IasTokenAuthenticator, XsuaaTokenAuthenticator) and the Spring security context adapter, and now depends on java-security-core
    • No API or behavior change for existing java-security consumers: all moved classes keep their fully qualified names and stay on the classpath transitively (minor release)
  • Keep the Spring Boot 3 starter's transitive Spring Framework dependencies on 6.x by overriding the parent Framework version
  • Update dependencies:
    • Spring Boot: 4.1.1 → 4.1.2
    • Spring Framework: 7.0.9 → 7.0.10
    • Spring Security: 7.1.1 → 7.1.2
    • Reactor (core & test): 3.8.7 → 3.8.8
    • Maven Surefire Plugin: 3.6.0 → 3.6.1
    • JaCoCo: 0.8.15 → 0.8.16
    • Spring Boot 3 / Spring Framework 6 / Spring Security 6 compatibility versions remain unchanged for the legacy modules

4.2.0

  • Distributed cache support for the internal token, JWKS, and OIDC discovery caches
    • The library's three internal caches previously lived only in the JVM's memory: after every restart or rolling deploy every pod re-fetched signing keys and re-issued its own tokens from XSUAA / IAS, causing cold-start latency and thundering-herd traffic against the identity services
    • New SecurityCache<String,String> SPI (java-api) behind all three caches; the in-memory Caffeine implementation remains the default, so existing applications see no behavior change
    • Two adapters ship out of the box: CaffeineSecurityCache (in-process default) and SpringCacheSecurityCache (wraps any Spring CacheManager backend such as Redis or Hazelcast); any other backend can be implemented against the SPI (copy-paste snippets in the main README)
    • Spring Boot: opt-in via sap.security.cache.distributed.enabled=true; the auto-configuration wires a SecurityCache bean from a user-supplied bean or a CacheManager cache named sap-security (configurable via sap.security.cache.distributed.cache-name) and fails fast with a clear error if no backing store is present
    • Plain Java: pass a SecurityCache to the DefaultOAuth2TokenService constructor (token cache) or JwtValidatorBuilder.withSecurityCache(...) / AbstractTokenAuthenticator.withSecurityCache(...) (JWKS + OIDC caches)
    • Cache entries are raw JSON strings and keys are namespaced (tokens:, jwks:, oidc:), so entries are safe to share across processes; token request fingerprints are SHA-256 hashed, so client secrets never appear in the key space or logs
    • Concurrent misses for the same key are collapsed into a single upstream call in all three caches (single-flight)
    • See the main README, section "2.5 Distributed Caching", for setup, bring-your-own-cache snippets, operational notes, and known limitations
  • Negative caching of stable JWKS retrieval failures
    • A /token_keys call that fails with a client error (4xx, e.g. a 404 for an unknown zone id) is now remembered for 30 seconds: repeated requests for the same invalid key fail fast with an exception instead of each triggering a new call to the identity service, so a stream of invalid tokens can no longer keep exhausting HTTP resources
    • Transient failures — server errors (5xx), timeouts, transport errors — are not negatively cached, so the next request retries immediately
    • After the 30-second window the next request retries the retrieval
  • CaffeineSecurityCache now honors per-entry TTLs
    • SecurityCache.set(key, value, ttl) durations shorter than the cache-wide default (as used by the 30-second negative cache entries) are now respected by the Caffeine adapter via Caffeine's Expiry policy; previously the per-entry TTL argument was ignored
  • Send the x-azp_app_tid request header when fetching IAS signing keys
    • When validating an IAS token, the azp_app_tid claim is now forwarded as an x-azp_app_tid header on the /token_keys request (only when the claim is present), mirroring the @sap/xssec 4.15.0 behavior
  • Update dependencies:
    • Jetty: 12.1.12 → 12.1.14
    • SLF4J API: 2.0.18 → 2.0.20
    • Mockito: 5.23.0 → 5.24.0
    • Maven Surefire Plugin: 3.5.6 → 3.6.0
    • org.json: 20260719 → 20260814

... (truncated)

Changelog

Sourced from com.sap.cloud.security:java-bom's changelog.

4.3.1

  • Retry token, token-key, and OIDC-discovery requests on network errors (token-client, token-client-spring, token-client-spring-3)
    • The retry feature previously only acted on configured HTTP status codes. A network error (connection reset, read timeout, TLS handshake error) was rethrown immediately, so transient network failures during access-token, JWKS, or OIDC-discovery retrieval were never retried — even with retry enabled and maxRetryAttempts configured. In the plain client this surfaced as Error retrieving token keys: null during short identity-service blips.
    • Affected classes now retry on network errors as well, bounded by the existing maxRetryAttempts and retryDelayTime:
      • DefaultOAuth2TokenService, DefaultOAuth2TokenKeyService, DefaultOidcConfigurationService (retry on IOException)
      • XsuaaOAuth2TokenService, SpringOAuth2TokenKeyService, SpringOidcConfigurationService (retry on ResourceAccessException)
    • The Spring variants additionally route retryable HTTP status codes (HttpStatusCodeException) through the same retry handling, so the configured retryStatusCodes now take effect even though RestTemplate surfaces non-2xx responses as exceptions.
    • An already-decided HTTP outcome (OAuth2ServiceException) is still never retried.
    • This aligns the behavior with the documented retry feature, which states that requests failing due to "network issues, such as timeouts or connection errors" are retried.

4.3.0

  • Split java-security into a new java-security-core module for Jakarta-free token validation
    • The token model (com.sap.cloud.security.token), the JWT validation packages (com.sap.cloud.security.token.validation, incl. JwtValidatorBuilder and all validators), com.sap.cloud.security.x509, and the TokenFactory ServiceLoader registration (via HybridTokenFactory) moved to java-security-core
    • java-security-core has no jakarta.servlet and no Spring dependencies, so token validation can be used from javax-based runtimes (e.g. Tomcat 9) without any Jakarta API on the classpath
    • java-security keeps the servlet-based authenticators (HybridTokenAuthenticator, IasTokenAuthenticator, XsuaaTokenAuthenticator) and the Spring security context adapter, and now depends on java-security-core
    • No API or behavior change for existing java-security consumers: all moved classes keep their fully qualified names and stay on the classpath transitively (minor release)
  • Keep the Spring Boot 3 starter's transitive Spring Framework dependencies on 6.x by overriding the parent Framework version
  • Update dependencies:
    • Spring Boot: 4.1.1 → 4.1.2
    • Spring Framework: 7.0.9 → 7.0.10
    • Spring Security: 7.1.1 → 7.1.2
    • Reactor (core & test): 3.8.7 → 3.8.8
    • Maven Surefire Plugin: 3.6.0 → 3.6.1
    • JaCoCo: 0.8.15 → 0.8.16
    • Spring Boot 3 / Spring Framework 6 / Spring Security 6 compatibility versions remain unchanged for the legacy modules

4.2.0

  • Distributed cache support for the internal token, JWKS, and OIDC discovery caches
    • The library's three internal caches previously lived only in the JVM's memory: after every restart or rolling deploy every pod re-fetched signing keys and re-issued its own tokens from XSUAA / IAS, causing cold-start latency and thundering-herd traffic against the identity services
    • New SecurityCache<String,String> SPI (java-api) behind all three caches; the in-memory Caffeine implementation remains the default, so existing applications see no behavior change
    • Two adapters ship out of the box: CaffeineSecurityCache (in-process default) and SpringCacheSecurityCache (wraps any Spring CacheManager backend such as Redis or Hazelcast); any other backend can be implemented against the SPI (copy-paste snippets in the main README)
    • Spring Boot: opt-in via sap.security.cache.distributed.enabled=true; the auto-configuration wires a SecurityCache bean from a user-supplied bean or a CacheManager cache named sap-security (configurable via sap.security.cache.distributed.cache-name) and fails fast with a clear error if no backing store is present
    • Plain Java: pass a SecurityCache to the DefaultOAuth2TokenService constructor (token cache) or JwtValidatorBuilder.withSecurityCache(...) / AbstractTokenAuthenticator.withSecurityCache(...) (JWKS + OIDC caches)
    • Cache entries are raw JSON strings and keys are namespaced (tokens:, jwks:, oidc:), so entries are safe to share across processes; token request fingerprints are SHA-256 hashed, so client secrets never appear in the key space or logs
    • Concurrent misses for the same key are collapsed into a single upstream call in all three caches (single-flight)
    • See the main README, section "2.5 Distributed Caching", for setup, bring-your-own-cache snippets, operational notes, and known limitations
  • Negative caching of stable JWKS retrieval failures
    • A /token_keys call that fails with a client error (4xx, e.g. a 404 for an unknown zone id) is now remembered for 30 seconds: repeated requests for the same invalid key fail fast with an exception instead of each triggering a new call to the identity service, so a stream of invalid tokens can no longer keep exhausting HTTP resources
    • Transient failures — server errors (5xx), timeouts, transport errors — are not negatively cached, so the next request retries immediately
    • After the 30-second window the next request retries the retrieval
  • CaffeineSecurityCache now honors per-entry TTLs
    • SecurityCache.set(key, value, ttl) durations shorter than the cache-wide default (as used by the 30-second negative cache entries) are now respected by the Caffeine adapter via Caffeine's Expiry policy; previously the per-entry TTL argument was ignored
  • Send the x-azp_app_tid request header when fetching IAS signing keys
    • When validating an IAS token, the azp_app_tid claim is now forwarded as an x-azp_app_tid header on the /token_keys request (only when the claim is present), mirroring the @sap/xssec 4.15.0 behavior
  • Update dependencies:
    • Jetty: 12.1.12 → 12.1.14
    • SLF4J API: 2.0.18 → 2.0.20

... (truncated)

Commits
  • e2bf023 fix(token-client): retry on network errors across plain + Spring clients (4.3...
  • d4212cf update maven central deployment name (#2067)
  • 85f9815 chore: prepare release 4.3.0 (#2065)
  • e67922c Build(deps): Bump the prod-deps-ver group across 1 directory with 15 updates ...
  • 8574c12 Feat/split java security core (#2032)
  • 0732e26 Build(deps-dev): Bump io.github.hakky54:logcaptor from 2.12.7 to 2.13.0 in th...
  • 1c25e8e Merge pull request #2053 from SAP/chore/dependabot-3.x-no-majors
  • eaa6bd6 Merge branch 'main' into chore/dependabot-3.x-no-majors
  • 6499a38 chore: stop Dependabot from proposing major upgrades on main-3.x
  • d44f48c Merge pull request #2051 from SAP/release-4.2.0-integration
  • Additional commits viewable in compare view

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

@dependabot
Bump the all-maven-dependencies group across 2 directories with 1 update
103e616 
Bumps the all-maven-dependencies group with 1 update in the / directory: [com.sap.cloud.security:java-bom](https://github.com/SAP/cloud-security-xsuaa-integration).
Bumps the all-maven-dependencies group with 1 update in the /srv directory: [com.sap.cloud.security:java-bom](https://github.com/SAP/cloud-security-xsuaa-integration).


Updates `com.sap.cloud.security:java-bom` from 4.1.2 to 4.3.1
- [Release notes](https://github.com/SAP/cloud-security-xsuaa-integration/releases)
- [Changelog](https://github.com/SAP/cloud-security-services-integration-library/blob/main/CHANGELOG.md)
- [Commits](SAP/cloud-security-services-integration-library@4.1.2...4.3.1)

Updates `com.sap.cloud.security:java-bom` from 4.1.2 to 4.3.1
- [Release notes](https://github.com/SAP/cloud-security-xsuaa-integration/releases)
- [Changelog](https://github.com/SAP/cloud-security-services-integration-library/blob/main/CHANGELOG.md)
- [Commits](SAP/cloud-security-services-integration-library@4.1.2...4.3.1)

---
updated-dependencies:
- dependency-name: com.sap.cloud.security:java-bom
  dependency-version: 4.3.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-maven-dependencies
- dependency-name: com.sap.cloud.security:java-bom
  dependency-version: 4.3.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-maven-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file java Pull requests that update Java code labels Nov 12, 2026
@mofterdinger
mofterdinger merged commit bc92738 into main Nov 12, 2026
2 checks passed
@mofterdinger
mofterdinger deleted the dependabot/maven/all-maven-dependencies-e87fded1d0 branch November 12, 2026 08:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mofterdinger mofterdinger mofterdinger approved these changes

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file java Pull requests that update Java code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@mofterdinger