Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aether-users] SNAPSHOT artifacts: how to best access timestamped files

Andreas Sewe wrote:

One question about SyncContext: When an Artifact is acquired, I would
typically want to synchronize on it in some way. Now, this IMHO requires
some canonicalization, as to Artifact objects may refer to the same
artifact in the repo. [...]  Does some kind of Artifact canonicalization
logic exist already somewhere?

No. Then again, simply synchronizing on the tuple groupId:artifactId:baseVersion shouldn't be too hard and provide a reasonable level of granularity/concurrency.

Anyway, something like that
would IMHO be very useful, as it seems quite error-prone to do if you
are not an Aether insider (yet ;-).

Agreed.

Now, in my scenario, where snapshots are stored with timestamps on disc
and are thus never overwritten by Aether, I want all threads to still
obtain an "old" snapshot of an artifact will Aether resolves a newer
one. So, instead of blocking and waiting for the download thread to
finish, the other threads should simply pick the previous snapshot from
disc.

As far as I can tell, this is not what SyncContext is supposed to do.
So, I'll probably better keep track of all the "in-flight" artifact
resolutions myself and answer with a cached, old Artifact until the
download thread finishes and updates the cache.

Yes, that sounds like the only way to achieve your goals.

Or does Aether have an internal cache that could kick in such a case,

To recap, the concurrency issue resides around the metadata backing the -SNAPSHOT resolution that ultimately is done by DefaultVersionResolver. If you look the sources for DefaultVersionResolver from the maven-aether-provider, you'll see it employs a cache for its results (unless disabled). That cache might fit your needs and is worth a try. In particular, you would want to check the properties that form the cache key to understand when a cache hit/miss is to be expected.


Benjamin



Back to the top