To be fair any assumptions made beside version handler is wrong, yet
determining if a given artifact version is release or not is something
which might fall across multiple places. Ideally it should be delegated
to Maven Resolver (formerly Aether) VersionScheme which is able to
specify version bounds through provisioning of specific version constraints.
Long time ago I made an attempt to switch version handling logic (just
for artifact resolver) and ended up with this prototype:
https://github.com/Code-House/maven-osgi-resolver
Maybe, with your puzzle, you simply reached to a fundamental design
question - if artifact alone can declare itself as a snapshot without
asking artifact resolver first?
Best,
Łukasz
On 31.08.2022 00:15, Henning Schmiedehausen wrote:
Team,
While tackling some issues around MNG-7529, I realized that there are
specific versions that can not be used for released artifacts. Specifically
any artifact whose version is shaped like the "SNAPSHOT_TIMESTAMP" format (
see
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java#L39)
will be treated as a snapshot independently whether it was loaded as part
of resolving a "xxx-SNAPSHOT" artifact from a remote repository or as an
actual released artifact.
While I understand *how* that happens (
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java#L48
,
https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/ArtifactUtils.java#L49
,
https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java#L229
all assume that any version that happens to match this pattern is a
snapshot, independently whether they are released or not), I am not sure
that this is the right thing to do.
IMHO, if an artifact is resolved out of remote snapshot metadata (IAW,
doing a foo-SNAPSHOT -> resolved artifact translation (the remote repos
store versions with immutable timestamps as
<groupId>/<artifactId>/<version>-SNAPSHOT/file-<version>-<timestamp>), this
translation is correct. However, if a release artifact is retrieved (which
is stored as
<groupId>/<artifactId>/<version-that-happens-to-be-timestamp-shaped>/file-<version-that-happens-to-be-timestamp-shaped>),
this mapping is *not* correct.
I know that this is probably a quite obscure situation, however I can
easily get maven to not be able to consume release artifacts with that
specific version shape. Integration test available on request. :-)
At the very least, this limitation should be documented so that users won't
stumble upon it. The format is not really that obscure;
eight-digit-date<dot>six-digit-time<dash>build-number may not be very
common but it is also not incredibly obscure.
I understand that "maven has always been that way and no one complained".
That does not mean that the behavior is correct IMHO.
-h
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org