Symptom
Downloading a snapshot knowledge artifact from Nexus fails with:
Download failed: java.io.IOException: Unexpected HTTP 404 downloading …
even though the dialog resolves the artifact, shows its size, and reports "Knowledge Artifact: Ready for Download". Releases are unaffected.
Root cause
MavenDataSourceDialogController uses the selected version verbatim as the version directory segment:
String directoryVersion = selectedVersion.strip(); // line 1295
…
URI downloadUri = MavenDataStoreDownloadTask.downloadUri(
repositoryUrl, coordinates, directoryVersion, fileVersion, classifier); // line 1323
For a remote repository the version combo box is populated from the Nexus component search, which returns the resolved, timestamped snapshot build (e.g. 1-chronology-builder-20260724.000852-12). Maven's repository layout stores those under the base directory 1-chronology-builder-SNAPSHOT/, with only the filename carrying the timestamp.
MavenDataStoreDownloadTask.downloadUri's 5-argument overload exists precisely to keep the directory version and the file version distinct, and its javadoc says so — but the caller passes the timestamp as both.
The local flow is already correct: it keeps X-SNAPSHOT in the combo box and calls LocalVersionResolver.resolveSnapshotFileVersion for the filename.
Evidence
Probed live against network.ike.foundation:ike-starter-set:1-chronology-builder-SNAPSHOT:reasoned-pb:
| URL shape |
result |
dir=…-SNAPSHOT, file=timestamped+classifier |
200 (correct layout) |
| dir=timestamped, file=timestamped+classifier |
404 (what the dialog requests) |
dir=…-SNAPSHOT, file=timestamped, no classifier |
404 |
dir=…-SNAPSHOT, file=…-SNAPSHOT+classifier |
404 |
Proposed fix
Derive the directory version from the selected version: when it matches Maven's resolved-snapshot form <base>-<yyyyMMdd.HHmmss>-<buildNumber>, the directory is <base>-SNAPSHOT; otherwise directory == selected version. Put the helper in MavenDataStoreDownloadTask beside downloadUri/localRepositoryPath (both need the same rule) and unit-test it.
Acceptance
- Downloading a timestamped snapshot build from Nexus succeeds.
- Release downloads keep the current behavior (directory == file version).
- Tests cover: resolved snapshot, plain
-SNAPSHOT, release, and a date-based release version that must not be mistaken for a timestamp.
Symptom
Downloading a snapshot knowledge artifact from Nexus fails with:
even though the dialog resolves the artifact, shows its size, and reports "Knowledge Artifact: Ready for Download". Releases are unaffected.
Root cause
MavenDataSourceDialogControlleruses the selected version verbatim as the version directory segment:For a remote repository the version combo box is populated from the Nexus component search, which returns the resolved, timestamped snapshot build (e.g.
1-chronology-builder-20260724.000852-12). Maven's repository layout stores those under the base directory1-chronology-builder-SNAPSHOT/, with only the filename carrying the timestamp.MavenDataStoreDownloadTask.downloadUri's 5-argument overload exists precisely to keep the directory version and the file version distinct, and its javadoc says so — but the caller passes the timestamp as both.The local flow is already correct: it keeps
X-SNAPSHOTin the combo box and callsLocalVersionResolver.resolveSnapshotFileVersionfor the filename.Evidence
Probed live against
network.ike.foundation:ike-starter-set:1-chronology-builder-SNAPSHOT:reasoned-pb:…-SNAPSHOT, file=timestamped+classifier…-SNAPSHOT, file=timestamped, no classifier…-SNAPSHOT, file=…-SNAPSHOT+classifierProposed fix
Derive the directory version from the selected version: when it matches Maven's resolved-snapshot form
<base>-<yyyyMMdd.HHmmss>-<buildNumber>, the directory is<base>-SNAPSHOT; otherwise directory == selected version. Put the helper inMavenDataStoreDownloadTaskbesidedownloadUri/localRepositoryPath(both need the same rule) and unit-test it.Acceptance
-SNAPSHOT, release, and a date-based release version that must not be mistaken for a timestamp.