feat: add in junit pioneer for testing

[codingsemen]

No description provided.

[github-actions]

Next minor release will be 4.6.0, Show Release Notes

4.6.0 (2025-05-21)

Features

• add in junit pioneer for testing (1db156f)

[github-actions]

Test Results

  234 files  ±0    234 suites  ±0   8m 8s ⏱️ -8s
1 150 tests  - 4  1 142 ✅  - 4   8 💤 ±0  0 ❌ ±0 
2 336 runs  ±0  2 316 ✅ ±0  20 💤 ±0  0 ❌ ±0 

Results for commit 8fa839f. ± Comparison against base commit aff1e01.

This pull request removes 4 tests.

org.sdase.commons.spring.boot.metadata.context.MetadataContextMergeIntegrationTest ‑ [4] {tenant-id=[t-c], processes=[p-c1, p-c2]}, {tenant-id=[], processes=[p-n3, p-n4]}, EXTEND, {tenant-id=[t-c], processes=[p-c1, p-c2, p-n3, p-n4]}
org.sdase.commons.spring.boot.metadata.context.MetadataContextMergeIntegrationTest ‑ [5] {tenant-id=[t-c]}, {processes=[p-n]}, EXTEND, {tenant-id=[t-c], processes=[p-n]}
org.sdase.commons.spring.boot.metadata.context.MetadataContextMergeIntegrationTest ‑ [8] {tenant-id=[t-c]}, {tenant-id=[t-n], processes=[p-n]}, KEEP, {tenant-id=[t-c], processes=[p-n]}
org.sdase.commons.spring.boot.metadata.context.MetadataContextMergeIntegrationTest ‑ [9] {tenant-id=[t-c], processes=[p-c]}, {tenant-id=[t-n]}, REPLACE, {tenant-id=[t-n], processes=[p-c]}

♻️ This comment has been updated with latest results.

[codingsemen]

I want to discuss 2 further things, what's the goto for declaring version in

ext {
  bouncycastleVersion = '1.80'
  logbackContribVersion = '0.1.5'
  springBootVersion = '3.4.5'
  springCloudVersion = '2024.0.1'
  scalaVersion = '2.13.16'
  swaggerCoreVersion = '2.2.32'
  victoolsVersion = '4.38.0'
}

vs declaring it directly on the import

api 'org.slf4j:slf4j-api:2.0.17'

Kind of confusing why we have both. Would like to stick to one way or another.
Also is there a convention on how to use String Literals in groovy?
I see a lot of variation between using '-text-' and "-text-" - i am a huge fan of conventions and uniform style but it's obviously not a dealbreaker to have both.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Some new discussion-topic was added

[mibutec]

I don't know if there is a general rule on this, so I can only speak for myself:

I prefer the direct approach for better readability

api 'org.slf4j:slf4j-api:2.0.17'

But if there are multiple dependencies with the same version I switch to the ext approach to ensure both libs are in sync

ext {
  slf4jVersion = '2.0.17'
}

api "org.slf4j:slf4j-api:${slf4jVersion}"
api "org.slf4j:jcl-over-slf4j:${slf4jVersion}"

This might also explain why sometimes singlequotes and sometimes doublequotes are used. In singlequotes ${...}won't get resolved

[JoergSiebahn]

I don't know if there is a general rule on this, so I can only speak for myself:

I prefer the direct approach for better readability

api 'org.slf4j:slf4j-api:2.0.17'

But if there are multiple dependencies with the same version I switch to the ext approach to ensure both libs are in sync

ext {
  slf4jVersion = '2.0.17'
}

api "org.slf4j:slf4j-api:${slf4jVersion}"
api "org.slf4j:jcl-over-slf4j:${slf4jVersion}"

This might also explain why sometimes singlequotes and sometimes doublequotes are used. In singlequotes ${...}won't get resolved

Exactly like this, preferred is single quotes and direct specification in the dependency and when there are multiple dependencies of a library that need or should have the same aligned version and do not have a bom managing the versions, extract the version to a property. However, this may not be kept consistent over time, e.g. otel deps had a lot of changes regarding what is managed in the bom and what has aligned versions that diverged later, etc.