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

Hi Benjamin,

>> Now, when prototyping this approach, I noticed that when resolving a
>> SNAPSHOT artifact, two copies of the file end up in your local
>> repository: One has a timestamp in its name, the other the string
>> "SNAPSHOT".
>>
>> I don't know exactly why this happens
> 
> Mostly for compatibility with Maven which I assume historically employs
> this to enable "mvn eclipse:eclipse" to produce .classpath files that
> can last more than a day, for example.

Yes, that makes sense.

> In the session's config properties, set
> aether.artifactResolver.snapshotNormalization=false
> and the -SNAPSHOT file is no longer produced and (remotely) resolved
> snapshots always point at the timestamped file.

Great! That solved my problem. Out of curiosity: Is this list of
properties documented somewhere (JavaDoc, Wiki, whatever)? Googling for
the property only turned up the source code.

>> On a similar note: Is there a way to find out whether an artifact
>> already exists in the local repository that doesn't either require
>> reconstructing a path (and thereby hardcoding the knowledge of how a
>> local repo looks like) or a "fake" artifact resolution in offline mode?
> 
> Depends. For starters, session.getLocalRepositoryManager() allows to
> construct pathnames for artifacts (getPathForRemoteArtifact() can be
> used to determine the path to the timestamped snapshot of a resolved
> artifact for instance). The same component also has a find() method to
> check local artifact existence (which is what the artifact resolver uses
> before going remote). However, with the above mentioned config property,
> one can't find a -SNAPSHOT artifact unless it was locally installed, for
> your remotely fetched snapshots, you would have to determine the
> timestamped version which requires a call to resolveVersion() (in
> offline mode).

OK, if I understand you correctly, if all I know is a "-SNAPSHOT" GAV
and I want to find the place on disk where the current timestamps
artifact (if already downloaded) resides, neither
getPathForRemoteArtifact() nor find() will help me (which my experiments
confirm). So, resolving in offline mode it is.

Now, this raises some further questions:

- I noticed that you wrote resolveVersion() above rather than resolve().
Is resolveVersion() followed by getPathForRemoteArtifact(), I assume,
preferable to resolve(). If so, why? Intuitively, I would have just
called resolve() as a one-stop solution.

- Having a second session around (one in offline-mode, on online) raises
the question how synchronization among sessions needs to be handled.

As far as I understand Aether's design, a RepositorySystemSession is
basically just a parameter object grouping lots of settings, so having
more than one session around is in itself not a problem. How this fares
in the face of multi-threading, however, I am not so sure (and I haven't
found any examples using SyncContext, which presumably has something to
do with it).

Anyway here's what I am trying to do:

- Given a "-SNAPSHOT" GAV, first check whether a timestamp artifact
exists in the local repo (presumably using resolution in offline mode).

- If it does not exist locally, schedule resolution of the "-SNAPSHOT"
GAV in online mode in another thread.

Now, I can guarantee that there is is only one online resolution job
running at any give time, but other threads might in the meantime
perform an offline-existance check using the local repo.

How to best do something like this using Aether? Any pointers are
greatly appreciated.

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


Back to the top