artifacts and release versions

[Henning Schmiedehausen <he...@schmiedehausen.org>]

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

Re: artifacts and release versions

[Henning Schmiedehausen <he...@schmiedehausen.org>]

On Wed, Aug 31, 2022 at 3:33 AM Tamás Cservenák <ta...@cservenak.net> wrote:

I do not understand why you felt the need to insert this into the thread,
but just to be clear.

But a word of warning to avoid any misunderstanding: Maven (and ASF AFAIK,
> at least from 2010) was always "stable = RTC".
>

To avoid any misunderstandings, *this* is the Apache Maven documentation:
https://maven.apache.org/project-roles.html

[...]
Formal roles

Committers

These are those people who have been given write access to the Apache Maven
code repository and have a signed Contributor License Agreement (CLA) on
file with the ASF.

The Apache Maven project uses a *Commit then Review policy* and has a
number of conventions which should be followed
[...]

emphasis by me. None of the conventions linked mentions anything otherwise.

-h

>
>

Re: artifacts and release versions

[Tamás Cservenák <ta...@cservenak.net>]

Howdy,

If one would choose the version layout "that happens" to be like you
describe, that would be really unfortunate.

The "timestamped snapshot version" was introduced in (very late) Maven2
AFAIR, Maven 3.0 allowed turning it off (while defaulted to using it), and
-- again AFAIR, someone correct me if am wrong -- since 3,1+ the option to
"turn it off" was removed.

The format is explained in several sites, just by googling I found these
few:
https://www.baeldung.com/maven-snapshot-release-repository
https://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html#pom-reationships-sect-versions
https://blog.sonatype.com/2008/05/maven-code-how-to-detect-if-you-have-a-snapshot-version/
(this is dated 2008, so 14 years old!)

Moreover, even some plugins are offering helping hand with snapshots, like
this one:
https://www.mojohaus.org/versions-maven-plugin/examples/lock-snapshots.html

---

Now, only to understand more easily what you are trying to say:
"artifact having $version matching pattern SNAPSHOT_TIMESTAMP should be
considered snapshot ONLY if its $baseVersion matches xxx-SNAPSHOT (ends
with SNAPSHOT)"?

The problem here is that if you look at Maven Artifact (classes you
linked), its properties version and baseVersion are LINKED/DERIVED
properties....
So if the artifact version is a timestamped version, the baseVersion WILL
BE xxx-SNAPSHOT.

Hence, when you declare a dependency in POM, you are giving only the
version (but not the baseVersion), or other way around (as for release the
two are the same), does not matter. Essentially you may set only one
(version), while the other is derived.

That said, Maven simply per definitionem cannot retrieve artifacts on path
like you describe, as in POM you set dependency "version", and from it is
"baseVersion" derived by Maven (layout).
Or in other words, for that to happen, you'd need to hand over BOTH
versions to maven (so to say "predefine" baseVersion, so no deriving is
needed), which currently is not possible.

---

Finally, re documentation... those links above I pasted are sadly NOT
coming from Maven site but elsewhere... Hence, we do have an ongoing effort
documenting the exact area we are discussing here, but it was a bit
disrupted (put on hold a bit) due our summer vacations... take a peek here:
https://github.com/apache/maven-site/pull/287

Helping hand with quality patches is always welcome!
But a word of warning to avoid any misunderstanding: Maven (and ASF AFAIK,
at least from 2010) was always "stable = RTC".
Branches like maven-3.8.x (stable, bugfix only for 3.8,x line), maven-3.9.x
(stable, upcoming 3.9.0) and yes, current master (weird, but maven4 is
there) are considered "stable" by the project team (per PMC).
Source: ApacheCon preso from 2010 (from Subversion times, so consider
"stable" as enumerated above, and "trunk" as rest, as with git thinks
changed a bit, so essentially you can fork or branch in same repo for PR)
https://www.erenkrantz.com/apachecon/JASIG%20-%20No%20Jerks%20Allowed.pdf


HTH
T


On Wed, Aug 31, 2022 at 12:15 AM Henning Schmiedehausen <
henning@schmiedehausen.org> 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
>

Re: artifacts and release versions

[Łukasz Dywicki <lu...@code-house.org>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org