Unable to Download v6.11.0 artifact through Gradle builds

[pramodburly]

We seem to be having issues in downloading the v6.11.0.133386 artifact from a build gradle. Could we publish a v6.11.0 ?
"implementation 'com.oneidentity.safeguard:safeguardjava:6.11.0.133386'" complains about " inconsistent module metaData found". Works fine through Maven pom based builds though

[bnicholesdell]

Can you provide more detail about what you are doing, what the issue is and why the current artifact doesn't work for you? Code examples and build script samples which demonstrate the issue, would be helpful.

[pramodburly]

Hi @bnicholesdell
Thanks for your response.

Here is a quick sample of a Gradle build driven repo. Intent here was to get the SG dependency artifact downloaded prior to it's usage. Ref: https://github.com/pramodburly/safeguardJavaGradleDemo

build.gradle was added with

implementation 'com.oneidentity.safeguard:safeguardjava:6.11.0.133386'

Error on build:

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve com.oneidentity.safeguard:safeguardjava:6.11.+.
     Required by:
         project :
      > Could not resolve com.oneidentity.safeguard:safeguardjava:6.11.0.133386.
         > inconsistent module metadata found. Descriptor: com.oneidentity.safeguard:safeguardjava:6.11.0 Errors: bad version: expected='6.11.0.133386' found='6.11.0'

Able to resolve the dependency on Maven builds though
Ref: https://github.com/pramodburly/safeguardJavaMavenDemo

[bnicholesdell]

The build number for SafeguardJava is set dynamically as the jar file is build using Azure Pipelines. So specifying the actual build number in the pom file itself isn't really possible. Have you tried using any of the version declarations that are discussed here. https://docs.gradle.org/current/userguide/rich_versions.html#rich-version-constraints

[pramodburly]

@bnicholesdell gotcha !
I haven't used Azure pipelines extensively, instead of updating the pom itself, would you have a way to publish the artifact with no buildNumber associated ? Similar to your .Net artifact ?

I did try quite a few variants from the link you shared too.. Haven't had any luck for any gradle builds
Here is a ref of the build outputs ReadMe

FYI: Builds work fine for older versions where the artifacts are published with no build number associated,
For example : 6.0.0 or 2.10.0

[pramodburly]

@bnicholesdell Following up. Any luck with addressing this or releasing a v6.11.0 or v6.12.0 artifact ?

[bnicholesdell]

Sorry, I haven't had time to look into this any further. I don't deal with Gradle much, so if you have any other suggestions about how this could be fix, that might help to move it forward.

[SkittishSloth]

Looking at the Azure pipeline, wouldn't it be possible to just remove the build id from the version variable on line 15? I would imagine that if there's any changes that justify a new build, you'd modify your version number accordingly (i.e. semver style), so the build id would be redundant.

Aside from that, the pom file doesn't incorporate the version from the pipeline at all; do you have any way to specify that when you update it from -SNAPSHOT? Perhaps some kind of external property or environment variable? I haven't played with maven in a very long time (and I wasn't great at it to begin with anyways), so I'm not sure what's possible. Regardless - and even if this wasn't causing problems - it's a little concerning that the released pom doesn't have the same revision as the accompanying artifact.

[bnicholesdell]

Azure pipeline, being a continuous build system, builds a new SNAPSHOT each time a change is made to the code and committed to the repository. The build id is the only way to differentiate one SNAPSHOT build from another during development of a major or minor release. It also saves the developer from having to manually update the version number for every code checkin.

The version is passed to the POM file on line #87 and #101 depending on the build type (SNAPSHOT vs RELEASE). The version number that is passed into the POM file, overrides the static version that was defined in the POM file. This is where Gradle has a problem. Gradle wants to match the static version number with the actual version number and finds a mismatch. It doesn't take into account that the actual version number was dynamically set. I was hoping that one of the version constraints that are listed in the web page reference previously, might fix the problem. But I don't do much with Gradle so I don't have an environment to test with.

[JakubGajewski]

Hey. same issue on my side. After upgrading to:
implementation("com.oneidentity.safeguard:safeguardjava:7.3.0")
and doing ./gradlew build, I'm getting:

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve com.oneidentity.safeguard:safeguardjava:7.3.0.210041.
     Required by:
         project :
      > Could not resolve com.oneidentity.safeguard:safeguardjava:7.3.0.210041.
         > inconsistent module metadata found. Descriptor: com.oneidentity.safeguard:safeguardjava:7.3.0-SNAPSHOT Errors: bad version: expected='7.3.0.210041' found='7.3.0-SNAPSHOT'