Inductiveautomation-thirdparty should return 404 for missing files

We are using inductiveautomation-thirdparty in our build to get the required third party dependencies to build against Ignition. This repository works correctly when asking for the main jar files (example) of those third party libraries. However, when asking for the -source or -javadoc jars (for IDE integration), it returns 401 (authentication required) instead of 404 (not found) (example). This means that the IDE will try again every time you synchronize the project, since theoretically the authentication failure could be transient. This wastes valuable developer time on unnecessary retries. 404s on the other hand are cached by all major build tools, since “not found” is generally considered to be a persistent problem.

This usually happens when you mix public and private contents in a Nexus virtual repository. I’d like to ask you to make inductiveautomation-thirdparty fully public, so it always either returns 200 or 404, but never 401. Any non-public contents should be moved to a private repository.

Thanks for bringing it to our attention. I’m going to look into this sometime this week, and will follow up on findings/changes once I’ve been able to dedicate some time to it.

Thanks for looking into it, any news on this?

Yes, we’re going to be making some changes to resolve this annoyance. It’s actually on my TODO list for this week, and I believe I’ll get to it today or tomorrow. I’ll post a followup when complete.

Now we are getting authentication errors for all dependencies in that repo, which is breaking our builds.

Updates/permissions changes are in progress, should be resolved shortly.

Updates are complete, and I am able to build the example modules in a clean environment. There should be permissions to read thirdparty source and doc jars (or fail with 404).

Do things seem to resolve as you expect?

Indeed, IDE sync is now fast without having to do any workarounds in our build files. Thank you :+1:

One more thing: has the same problem (querying sources gives 401), so we still need workarounds for this one. Would be great if you could do the same fix there.

Ok, I’ve made a note and will take a look (won’t take as long as this change, but won’t be able to get to it today).