check failed: exit status 22

[elgohr]

When the resource is used without a former put, e.g.:

resources:
  - name: snapshot
    type: maven-resource
    source:
      url: *__ARTIFACTORY_RELEASE_URL__
      snapshot_url: *__ARTIFACTORY_SNAPSHOT_URL__
      artifact: *__ARTIFACTORY_ARTIFCAT___

jobs:
  - name: job
    plan:
      - get: snapshot
        trigger: true
      - task: do-whatever
...

And the url and snapshot_url are filled, like shown above, the resource uses the url to get the version from the maven-metadata.xml. The snapshot_url will be ignored.
Should this probably be documented?

When there is no url/.../maven-metadata.xml, it fails to get the version via curl, even if there would be a snapshot_url/.../maven-metadata.xml
This results in the following error

The error message in check (line 76) is not shown and debugging is not that easy.

[dkothari-clgx]

I agree up top. Its weird that you have .version.version but you cannot target a SNAPSHOT. Unfortunately, resources does not allow
version:
version: *-SNAPSHOT
it should go under source.version for the check, in, and out or in params.

EDIT:

maven-resource/assets/check

Line 31 in 4543920

version=$(jq -r '.version.version //empty' < $payload)

That line does not work for concourse.

[patrickcrocker]

I've fixed the error reporting (1.3.7-rc.8) so that it is easier to understand what failed. Now you should see something like this:

[ERROR] curl: (22) The requested URL returned error: 404
[ERROR] failed to download maven-metadata.xml from: https://nexus.nulldriver.com/repository/maven-releases/com/nulldriver/does-not-exist/maven-metadata.xml

The statement about line 31 not working for Concourse is not correct. Concourse passes in the last known version of the resource as .version.version. I do acknowledge that this value will be empty for the case that the resource does not exist yet. How the maven-resource handles this is now up for debate. :-)

At this point I'm second guessing my decision to support both url and snapshot_url... It seems that if you need to make that level of distinction in your pipeline, you should probably have two defined resources, one for snapshot and one for releases... thoughts?

[designed4device]

Agreed, I prefer the snapshots and releases to be separate resources in my pipelines for clarity. In the resources current state, it appears to be a necessity for the use case of a pipeline that is only using the resource for gets in order to retrieve a snapshot.
I think supporting a single url param would reduce some complexity in the codebase and make the resource's functionality a bit easier to understand.

[designed4device]

@patrickcrocker I ended up doing an overhaul in my fork that included removing the snapshot_url param. Have you thought any further on removing it for this repo?

[patrickcrocker]

Yes, and I'm getting ready to focus more effort on this resource (I've been focused on cf-cli-resource for a while). I'll be working on this resource starting next week and hope to provide more direction and some much needed updates. I'll take a look at your fork as well!

[designed4device]

If you're ready to remove it now, I'd be happy to open a pull request.