ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <arc...@dellroad.org>
Subject Re: Is there a resolver that is not tightly coupled to filesystem semantics?
Date Thu, 15 May 2008 16:09:39 GMT
You can do this already.

E.g., imagine using an URL resolver with:

  <ivy pattern="
http://my.repo.com/ivy?org=[organisation]&mod=[module]&rev=[revision]"/>
  <artifact pattern="
http://my.repo.com/artifact?org=[organisation]&mod=[module]&rev=[revision]&artifact=[artifact].[ext]
"/>

Then just configure your HTTP server to do whatever it needs to get the
right stuff.

For example, in Apache an URLrewriter can convert these URLs back into a
local filesystem location.

In other words: that correspondence between URL "layout" and filesystem
layout is just one of convenience. There doesn't have to be any actual
correspondence if your HTTP server knows how to interpret whatever URL it
gets.

-Archie

On Thu, May 15, 2008 at 10:36 AM, Brown, Carlton <
Carlton.Brown@compucredit.com> wrote:

> 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.
> ====================================================




-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message