ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brown, Carlton" <Carlton.Br...@compucredit.com>
Subject Is there a resolver that is not tightly coupled to filesystem semantics?
Date Thu, 15 May 2008 15:36:58 GMT
Hi all,
 
As far as I can see, every documented Ivy resolver requires an
<artifact> element and <ivy> element, each of which requires some
knowledge of how the repository is laid out.   This means if I want to
re-arrange a popular and heavily used repository, there has to be a
corresponding change for every ivy-settings.xml in the wild that
references this repository.   I understand namespaces can help, but even
namespaces are stored in ivy-settings.xml and thus suffer from the same
problem.
 
If we had some sort of resolver that was completely orthogonal to
directory layout, this wouldn't be a problem.   There could be a
resolver whose only non-generic attributes are a hostname and port.
The host would be running some server which in turn would use ivy to map
those requests to a physical storage implementation (filesystem, dbms)
or maybe even delegate it to a subordinate resolver.   In this way, the
client would never need to know which implementation served the request,
it could be just concerned with getting the content.
 
Does any such resolver exist?  Could it be easily created by extending
abstract resolver and adding the behavior, or is there a lot of baked-in
filesystem stuff in there?
 
Thanks,
Carlton



-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the 
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on 
the contents of this message is prohibited. In such
case please notify us and destroy and delete all 
copies of this transmission.  Thank you.
====================================================
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message