DEV Community

Query Filter
Query Filter

Posted on Edited on

desktop-3

#bash #linux #cli #productivity

When two branches (like your Java 8 baseline and your new Java 21 branch) publish artifacts under the exact same version string, Artifactory's repository search order and metadata caching will inevitably cause collisions.

While you wait for permissions to delete the conflicting artifact from Artifactory, you can bypass the issue using several developer-side or build-side workarounds:

1. Temporarily Bump or Suffix the Version on the Java 21 Branch (Fastest & Cleanest)

Instead of fighting Artifactory resolution order, change the version identifier on your Java 21 branch so it completely stops colliding with the main branch.

  • In Gradle (build.gradle): Update the version string to include a distinct classifier or suffix: 
version = '1.2.3-JAVA21-SNAPSHOT' // or increment the patch version to 1.2.4-SNAPSHOT
Enter fullscreen mode Exit fullscreen mode
  • In Maven (pom.xml): 
<version>1.2.3-JAVA21-SNAPSHOT</version>
Enter fullscreen mode Exit fullscreen mode
  • Why this works: Parent applications looking for the standard release or baseline snapshot version will completely ignore this unique string, letting them safely pull the stable version while you continue working on Java 21 isolation.

2. Force an Override via Parent App Build Configuration

If you have access to the parent applications that consume your library, you can explicitly force them to resolve a specific version or bypass the conflicting Artifactory path.

  • In Gradle (Parent App): Use a resolutionStrategy to force the exact baseline version you want, or substitute the module: 
configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.name == 'comet-dds') {
            details.useVersion '1.2.2' // Force the stable non-Java21 version
        }
    }
}
Enter fullscreen mode Exit fullscreen mode
  • In Maven (Parent App): Use <dependencyManagement> to pin the dependency to the known working version globally across the parent project modules.

3. Change the Target Publication Repository in Your CI/CD Pipeline

If your Java 21 branch pipeline is automatically pushing snapshots/releases to the same Artifactory repository that parent apps scan first:

  • Temporarily redirect the deployment target in your pipeline script (e.g., Tekton or Harness) to publish the Java 21 artifacts to a staging, local, or dev-specific repository instead of the main shared enterprise repository.
  • This keeps the build pipeline functional for testing your Java 21 branch without polluting the artifact feed that parent apps consume.

4. Leverage Local Maven Cache (~/.m2 or ~/.gradle) for Local Testing

If you are testing the parent applications locally alongside your library changes:

  • Run ./gradlew publishToMavenLocal (or mvn install) from your Java 21 branch.
  • In the parent application, configure your build to prioritize mavenLocal() so it uses your locally built artifact rather than querying the remote Artifactory server.

Top comments (0)