Interesting. Thanks.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Archie Cobbs > Sent: Thursday, May 15, 2008 12:10 PM > To: [email protected] > Subject: Re: Is there a resolver that is not tightly coupled > to filesystem semantics? > > 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=[re > vision]"/> > <artifact pattern=" > http://my.repo.com/artifact?org=[organisation]&mod=[module]&re > v=[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 < > [EMAIL PROTECTED]> 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 >
