Using a different endpoint won't do anything in most cases other than effectively disable the analyzer. Have you looked at #7686 (comment)?

@jeremylong Isn't the content supposed to return a pom.xml file? I could take the POM file from my own repository without involving the Central analyzer. Aren't these two entirely different entities?

Sorry - I was thinking of the Central Search API.

This doesn’t feel right to me. Shouldn’t one just enable the Nexus or Artifactory analyzers instead? This seems to add complexity but I am not sure in which use case this helps?

@chadlwilson Analyzers for Central/Nexus/Artifactory are a slightly different topic. Yesterday, I encountered an error specifically related to uploading a pom.xml file, likely due to a 502 error in the Maven repository.

[WARN] Unable to download pom.xml for antlr-2.7.7.jar from Central; this could result in undetected CPE/CVEs.
[WARN] Unable to download pom.xml for asm-9.8.jar from Central; this could result in undetected CPE/CVEs.
[WARN] Unable to download pom.xml for hamcrest-3.0.jar from Central; this could result in undetected CPE/CVEs.
[WARN] Unable to download pom.xml for hamcrest-core-3.0.jar from Central; this could result in undetected CPE/CVEs.
[WARN] Unable to download pom.xml for jspecify-1.0.0.jar from Central; this could result in undetected CPE/CVEs.
[WARN] Unable to download pom.xml for junit-4.13.2.jar from Central; this could result in undetected CPE/CVEs.

My version of Artifactory does not support component analysis (XRay), and I understand that dependency-check relies on the results of the XRay analyzer.

I dont think it's a separate topic, no, because its an alternate pom source to Central for those scanning jars. Similar to Nexus. Don't think it needs x-ray. Have you tried it?

I still don't understand what the use case of this is. If you're not pointing it at Central where are you pointing it at exactly, and what is replacing the search?

Anyway, given the underlying url setting/property already exists, I guess I don't have a huge objection, I just think the configuration interface gets more and more confusing and we end up with more and more questions from confused users the more that is exposed.

Okay, to avoid complicating the interface by adding new CLI parameters, let's wait for the Maven Central issues to be resolved. I just wanted to have the option to load pom.xml files from another source in case of a failure.

More complex scanner settings are not stored in --help parameter but are located in --advancedhelp parameter, meaning there is already a separation for deeper scanner configuration.

That is the purpose of the Artifactory and Nexus Analyzers and running your own infra as a proxy: #7992 (comment) - these 3 analyzers are essentially all "alternate POM sources".

I tried connecting Artifactory to scanning several times, but it didn’t work. I couldn’t find any helpful information in the logs. Is there perhaps an example of usage somewhere?

It shouldn't be too complicated, but depends on your Artifactory setup.

https://dependency-check.github.io/DependencyCheck/dependency-check-cli/arguments.html

path/to/odc/bin/dependency-check.sh \
-s . \
--disableCentral \
--enableArtifactory \
--artifactoryUrl https://my-server/artifactory \
--artifactoryUsername $ARTIFACTORY_USER \
--artifactoryApiToken $ARTIFACTORY_TOKEN \

@chadlwilson Thank you for the tip. I was only missing the --disableCentral parameter, which wasn’t obvious to me, as the documentation for the --disableCentral parameter states that it’s necessary to disable other analyzers (Artifactory/Nexus) as well. It would also be great to specify in the --enableArtifactory parameter that --disableCentral needs to be enabled: https://dependency-check.github.io/DependencyCheck/dependency-check-cli/arguments.html.

Yes, that is misleading/wrong - also noted at #7988

PR to improve the documentation is welcome :-)

So this PR can be closed?

I think it's your call @jeremylong - if you think it makes sense to further expose the existing central.content.url setting to the CLI, we can do so. However I can't really think how this makes sense. If Maven Central Search is working but the content URLs are not - is it really valid to overwrite the content URL, or change it to a direct URL? Since you cannot replace the Maven Central Search API with your own, it seems you cannot safely override the content URL either.

From the other Maven/Gradle plugins I guess it's already possible to override this property using Java system properties.

Having said all this, if you'd rather leave this code untouched until Sonatype work out the future of the Maven Central search API, that might make as much sense. For all we know, a future implementation will return fully qualified POM URLs to follow anyway.

@chadlwilson can you see my PR for docs #7999