[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aether-users] How to avoid fallback to literal "-SNAPSHOT" version when resolving SNAPSHOTS?
|
Hi Benjamin,
>> Now, if the checksum of maven-metadata.xml is
>> wrong, Aether falls back to trying to resolve the artifact with a
>> literal version of "1.0.0-SNAPSHOT". But this can never succeed for a
>> *model* repository.
>>
>> Is there some easy way to change this behavior
>
> Change to what exactly? You configured the system to reject stuff with
> mismatching checksums, now the metadata is rejected preventing the
> resolution of the timestamped snapshot. What other than an error do you
> expect out of this?
Well, there is a situation where Aether does not produce an error, but
based on my setting of CHECKSUM_POLICY_FAIL I would expect one. Consider
the following remote repository:
org/example/data/1.0.0-SNAPSHOT/maven-metadata.xml
org/example/data/1.0.0-SNAPSHOT/maven-metadata.xml.sha1 (mismatch!)
org/example/data/1.0.0-SNAPSHOT/data-1.0.0-SNAPSHOT.jar
org/example/data/1.0.0-SNAPSHOT/data-1.0.0-SNAPSHOT.jar.sha1
Now, what happens if Aether has to resolve
org.example:data:1.0.0-SNAPSHOT? Aether starts by downloading
maven-metadata.xml(.sha1) and encounters the checksum mismatch. Then,
instead of giving up (that was my assumption/intention) it falls back on
downloading data-1.0.0-SNAPSHOT.jar (with a literal "SNAPSHOT" in the
URI). Now, in the above repository, where data-1.0.0-SNAPSHOT.jar exists
and has a matching checksum, you may argue that Aether is correct in
succeeding to resolve org.example:data:1.0.0-SNAPSHOT.
In case of a Code Recommenders model repository, however, I can
guarantee that no "literal" SNAPSHOTs are stored therein; all SNAPSHOTs
are timestamped. Hence, failure to download (because of a checksum
mismatch) maven-metadata.xml should *not* result in a useless HTTP
request for data-1.0.0-SNAPSHOT.jar. Granted, this just avoids some 404
traffic and is hence not super-critical, but this level of
control/configurability would nevertheless be nice to have (in 1.1.,
perhaps?).
Best wishes,
Andreas
--
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
