Artifactory outdated maven-metadata.xml for public/com/github/jnr/jnr-posix/

[jonesbusy]

Service(s)

Artifactory

Summary

Hi,

While investigate why dependabot didn't found a new release on https://github.com/jenkinsci/jnr-posix-api-plugin/actions/runs/12630790439/job/35191287139

Original artifact are hosted on maven central : https://repo1.maven.org/maven2/com/github/jnr/jnr-posix/

Latest release is 3.1.20. Maven metadata is correct https://repo1.maven.org/maven2/com/github/jnr/jnr-posix/maven-metadata.xml

But on our Jenkins artifactory public repo it's not https://repo.jenkins-ci.org/public/com/github/jnr/jnr-posix/maven-metadata.xml

It's still indicate 3.0.61 even if 3.1.20 was downloaded (I did a build locally, and it's resolved)

Why the maven-metadata is incorrect ?

Might be related to foreign release #4444 ?

Can we try maybe to invalidate this maven-metadata.xml ?

Thanks

Reproduction steps

No response

[dduportal]

After a check in Artifactory:

• The artefacts are now available and the maven-metadata.xml is now valid
• The com/github/jnr/* tree comes from the mirror atlassian-maven-public-cache (https://repo.jenkins-ci.org/artifactory/atlassian-maven-public/ which mirrors https://packages.atlassian.com/maven-public/).

(Edited) The "broken" metadata most probably come from the atlassian remote repository.

[dduportal]

Now comes the billion dollar question: why do we have this repository still there :| Gotta search our old issues

[dduportal]

Now comes the billion dollar question: why do we have this repository still there :| Gotta search our old issues

Comes from #3950

[dduportal]

Ping @daniel-beck @MarkEWaite @basil I can't recall the state of our setup for atlassian-maven-public-cache. I'm currently digging the old issues, but I fear I did not report with due diligence the next steps and now my memory betrays me.

Is there a path in which we want to remove this from the public/ virtual repository (which allows specific project to rely on it, but not all)?

[dduportal]

@jonesbusy is the problem solved on your side now?

[jonesbusy]

For me https://repo.jenkins-ci.org/public/com/github/jnr/jnr-posix/maven-metadata.xml still indicate 3.0.61

[MarkEWaite]

Ping @daniel-beck @MarkEWaite @basil I can't recall the state of our setup for atlassian-maven-public-cache. I'm currently digging the old issues, but I fear I did not report with due diligence the next steps and now my memory betrays me.

I recall that we intentionally added one or more Atlassian public caches because they provide open source components that some of our plugins require. I believe that we stopped mirroring the Atlassian caches that included more than open source components so that we would more easily detect the use of a proprietary component.

I believe more history is available at:

• Remove jcenter, and oss.sonatype.org-releases repositories from public virtual repository; reconfigure Atlassian remote repositories #3842
• declarative-pipeline-migration-assistant-plugin no longer compiles #3872

[jonesbusy]

Do we have a way to exclude some path or define order in the virtual repository?

[dduportal]

Do we have a way to exclude some path or define order in the virtual repository?

Absolutely, that would be the most porbable "short term" fix for the org/github/jnr/**/* tree. But if we can even stop mirroring a whole repo, or only includes what we need (yes, excludes AND includes are available)

[timja]

Includes would be preferable here

[dduportal]

Includes would be preferable here

Yep, but switching to include might break some projects hence my question about recollections.

naive question : do we have a technique to check dependencies across jenkinsci projects?

[jonesbusy]

Includes would be preferable here

Yep, but switching to include might break some projects hence my question about recollections.

naive question : do we have a technique to check dependencies across jenkinsci projects?

I wish, perhaps one day with https://github.com/jenkins-infra/plugin-modernizer-tool

[dduportal]

Proposal

Let's only mirrors the artifacts of atlassian-maven-public which are part of the tree com/atlassian/**/* by using include patterns.

As per #3842 (ref. #3842 (comment), #3842 (comment), #3842 (comment))

=> it restricts the mirrored artifacts but not too aggressively.

Note: it might have an impact on the crowd2 plugin though (ref. #3842 (comment)): if we agree to perform this change, then we'll have to monitor it carefully
Crowd2 is not distributed anymore as per #3854

[jonesbusy]

Looks goods

[timja]

Let's only mirrors the artifacts of atlassian-maven-public which are part of the tree com/atlassian/**/* by using include patterns.

Sounds reasonable and should fix this and the other issue #4444

We can easily add more includes if required.

cc @olamy as Jira plugin maintainer for FYI