Xavier Hanin wrote:
The operation I see for the moment are very basic, and would be very
similar to a part of what can currently be found in CacheManager. For
instance:
File getArchiveFileInCache(Artifact artifact)
File getIvyFileInCache(ModuleRevisionId mrid)
ArtifactOrigin getSavedArtifactOrigin(Artifact artifact)
I don't know if getSavedArtifactOrigin(Artifact artifact) will
actually be necessary. Maybe we could make this interface simpler with
something like:
File getArchiveFile(Artifact)
=> returns the location of the artifact as a File, which can be either
in the cache or at it's original location if the artifact is not
cached but used directly. We could use this method also for Ivy files
(using DefaultArtifact.newIvyArtifact(ModuleRevisionId mrid, Date
pubDate) as artifact).
File getLocation(Artifact)
String getOriginLocation(Artifact)
=> returns the location of an artifact in the repository. This is
usually an URL, but depends on the DependencyResolver implementation.
This would usually be used for reporting only.
String getSource(Artifact)
I really don't like having a String like this. In which case can this
not be a URL ?
And I think this method should be part of the artifact, not the cache.
(ie: Artifact.getSource())
To make BasicResolver actually able to delegate to the
ResolverCacheManager, we should also add methods like:
void cacheArtifact(Artifact, InputStream)
=> copies the input stream to the cache file for the given artifact
So where do you get the source (origin) from if you don't have the
source of the stream ?
I have a hard time seeing the difference with a cache and nullcache.
Indeed now that I push the reflection further I have troubles to
clearly see the separation of responsibilities between the resolver
and the cache. Indeed to implement the method
getArtifactFile(Artifact), the cache manager can know the answer only
if it actually caches the artifact file. If it doesn't cache it, only
the resolver can know it.
Well, the resolver resolves. I gets artifacts information and needs to
download the artifact and store that binary along with the artifact
information into the cache.
Stupidely speaking, if there is a null cache on a http resolver, it
would need to ping the server each time and download it each time.
It does not make much sense to have a cache on a filesystem resolver so
the copy of the gazillions of jar could be disabled by setting a
nullcache for this resolver.
So maybe a solution is to cache the origin location (as is currently
done in CachedDataFile) to be able to return this location. This means
that even a nullcache would have to persistently store the origin
location of artifacts.
The origin must always be there to me. Why not add it to the information
carried by the artifact itself ?
[...]
What do you mean by the attributes of the artifact? Are you speaking
about something in memory, or persistent?
In memory the Artifact object when it is created do not know anything
about its actual location. Moreover retrieving the source location of
an Artifact can be a costly operation, because you have to delegate to
dependency resolver. That's why I think that keeping the
ArtifactOrigin object separated from the Artifact has a sense.
Well, you have to get the source location from somewhere, so in any case
the resolver went to it already before right ?
Concerning the persistent storage of information concerning the
artifact, the artifact file itself cannot be modified to store this
metadata, that's why we have to store them in a separate file. Do you
see another option?
I'm not sure I fully understand what you mean.
I think it depends if you consider the artifact as content or as an
information holder.
Frankly I don't see much the difference between what is trying to be
done and an asset management system or file system that has in one place
the information regarding metadata of the asset/file and a link to a
physical location where is stored the binary.
BTW, now that I think more about the problem, I think we will even
still need to store the resolver and artifact resolver information, at
least when the resolver directly associated with the Module is a
compound resolver. Otherwise we would have to go through the compound
resolver itself whenever we want to reload the module from cache. This
should be the responsibility of the compound resolvers cache, so that
we can avoid to store this information when not necessary.
Xavier
