[
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:
pardon the quite lengthy post this time, but my last question posted
here has taught me that it is better to really describe what you want to
achieve:
Yes indeed, though I think sharing the greater picture is useful for any
help inquiry.
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.
as far as I understand Aether,
the timestamped file won't be overwritten by a newer SNAPSHOT resolved
later
That's correct.
There is one minor problem, however:
artifactResult.getArtifact().getFile() points to the "SNAPSHOT" file,
not the timestamped one. Now, artifactResult.getArtifact().getVersion()
has its SNAPSHOT replaced by the timestamp, so it is certainly possible
to reconstruct the path inside the local repository on your own, but
this seems a bit clunky. So, is there a more direct way to get a
java.io.File pointing to the timestamped file?
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.
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).
Benjamin