Maven dependencies in local REPO have .lastUpdated extension

It also can happen when you refer to the artifact which is listed under Maven Repository but is not there physically. E.g., the following Exasol artifact is listed under Maven Repository, but there's a small side note which tells that:

Note: this artifact i[s] located at Exasol repository (https://maven.exasol.com/artifactory/exasol-releases/)

This means that you need to separately add another repository (in this case Exasol) as a source in your pom.xml file:

<!-- add the dependency as mentioned in maven website -->
<dependencies>
    <dependency>
        <groupId>com.exasol</groupId>
        <artifactId>exasol-jdbc</artifactId>
        <version>6.2.1</version>
    </dependency>
</dependencies>

<!-- add the actual repository which unfortunately isn't mentioned in maven website -->
<repositories>
    <repository>
        <id>maven.exasol.com</id>
        <url>https://maven.exasol.com/artifactory/exasol-releases</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

I've found the answer here :

When an artifact is unable to be downloaded, Maven 3 caches this result for future reference in the "~/.m2/repo/.../.lastUpdated" file. For "not found" situations, it seems that the HTTP code could be used to more granularly re-attempt retrieval rather than just cache the failure. For example, for any 404, I agree, the result should cache the failure and require a -U to attempt to retrieve it again. However, for 400, 500, 501, 502, 503, 301, 302 (what's the Maven behavior for 3xx today?) I think the resolution engine should try to re-retrieve the artifact each time. With those error codes, it seems more likely a config issue or brief network hiccup, not one of the file being absent from that repo. However, that brief network hiccup has longstanding cache implications in that the file is never attempted to be retrieved again.