ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Is there a resolver that is not tightly coupled to filesystem semantics?
Date Mon, 26 May 2008 08:27:19 GMT
On Thu, May 15, 2008 at 6:09 PM, Archie Cobbs <archie@dellroad.org> wrote:

> 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]<http://my.repo.com/ivy?org=%5Borganisation%5D&mod=%5Bmodule%5D&rev=%5Brevision%5D>
> "/>
>  <artifact pattern="
>
> http://my.repo.com/artifact?org=[organisation]&mod=[module]&rev=[revision]&artifact=[artifact].[ext]<http://my.repo.com/artifact?org=%5Borganisation%5D&mod=%5Bmodule%5D&rev=%5Brevision%5D&artifact=%5Bartifact%5D.%5Bext%5D>
> "/>
>
> 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.


There is one problem with this approach: directory listing, which Ivy needs
to handle dynamic revisions. I think you'd need to subclass the URLResolver
to handle dynamic revisions with some specific URL.

With the first implementation of Ivy we use to have a servlet running on a
server and the corresponding resolver. I never released this as part of Ivy
because the code was too tighly coupled to our infrastructure. But the
servlet and the resolver were very easy to write. With restlet it could even
be easier today.

Xavier


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



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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