> Stanley,Michael P. wrote: > > >I just don't think you see it. This still forces a developer to know > >the URL of the jar - > >"http://www.ibiblio.org/maven/ant/jars/ant-1.4.1.jar";. > > > >What happens if the dependency moves. Every POM that has that hardoced > >URL fails. > > > ><dependency> > > <id>ant</id> > > <version>1.4.1</version> > > <groupId>org.apache</groupId> > ></dependency> > > > >This tells me everything I need to get to the repository (regardless of > >where it is, or how the PRS is organized!) > > > > > I don't think you see it either. I am perfectly aware that adding a > layer of indirection to looking up something allows you to get anywhere > you like. I am not proposing removing this ability with the URL stuff. > I am proposing that I can just specify the URL if I know where the heck > something is.
Your right I didn't get it :-). I can see how this would be useful for a single developer, but for this to work across a team - they would need to have the same file:/// structure. (or corporate fileserver mapped to the same point). And if you change it to use http:/// or another protocol you fall under the same fate - to a move in the repository. > For example on my PC right now I have javamail jars in > "file:///lon_fp1/developers/packages/javamail-1.3/lib/imap.jar" (etc) - > being used by ant-based projects. In order to use this in maven right > now, I'd have to copy it, rename it, or provide metadata for it. Why? I > /know/ this file isn't going to move off the corporate fileserver. Why > can't I just write: > > <dependency> > <id>imap</id> > > <location>file:///lon_fp1/developers/packages/javamail- > 1.3/lib/imap.jar</location> > </dependency> Yeah, I understand what you are getting at now. > Does this stop you writing metadata for other packages? No. Does it get > the project up and running faster? Yes. Faster is debatable :-) > Will this break in the future? eg, lon_fp1 gets replaced by lon_fp2. > Actually, no, it doesn't. Not if I can provide an equivalent location > for that URL, e.g: > maven.repo.remote=file:///lon_fp2/developers/maven > file:///lon_fp1/developers/maven > (see comments below about uses of mirrors...) > > >The Ant project can name the resource foobar and put it in their donkey/ > >folder. It doesn't matter. The contract is on the Dependency ID and > >the Group ID and optionally the version and artifact. > > > >Give me a situation this doesn't hold true on. > > > > > Of course there isn't one. Indirection is a panacea. But its a panacea > with a cost. What's the cost? There is a cost with everything of course, and I'm trying to minimize cost through design and discussions. With a default base structure, and optional meta-data for extensibility purposes, I think this becomes is a minimal cost solution. > >What I'm proposing can not be compared to Mirrors. Mirrors are good at > >distributing load, and providing faster resources based on geographical > >location. However, they do not provide a de-centralized service. There > >is big difference to the Maven build system and Linux distribution > >sites. The Maven repository/dependency resolution system should not > >imitate distro-sites. > > > Its a different aspect of mirrors that interests me. The file structure > of silos, repos - whatever you care to call them - within sets of > mirrors is identical. I can try to get the same file from a selection of > mirrors (even incomplete mirrors) by using the same relative path. Once > you know the url to a file on one of a set of mirrors, its trivial to > find out if its on any of the others. Agreed. I'm arguing to utilize the DNS protocol to determine this base path. > To achieve the same effect purely with metadata you need to have an > entire catalog for the repository in your metadata, or equivalently a > lookup service (eg LDAP, as you say). I'm not saying you can't do this > stuff with metadata. What I am saying is that the observation that > repositories are currently mirrors (in the sense of sharing the same URL > structure) is useful as it allows us to take eg: I'm not saying there needs to be a repository meta-data. The repository should be structured from groupID (series of sub-directories matching reverse domain pattern). > maven.repo.remote=http://www.ibiblio.org/maven > file:///lon_fp1/developers/maven > > and from that determine that: > http://www.ibiblio.org/maven/ant/jars/ant-1.4.1.jar > > belongs in this set of mirrors (it starts with the name of one of the > mirrors) and thus may also be available at: > file:///lon_fp1/developers/maven/ant/jars/ant-1.4.1.jar Is this any different than how the lookup works today? local -> remote list > Knowing that I can work with mirrors this way is what /lets me/ specify > a dependency as an URL and still manage to get it from multiple repos. > It also allows me to observe that this use of URLs would allow for sets > of mirrors with /different/ URL structures, the structures only being > equivalent within each set (and this does 'decentralize' repo stuff). > > Splitting the local repo to have a separate per-repo cache allows me to > avoid name clashes on downloaded artifacts without requiring metadata to > exist. Once we have the metadata and some global naming strategy we > could get the same thing, but the cache structure prevents us ever > having name clashes, and can be put in place right now. (after patching > the 15 plugins that 'know' the structure of maven.repo.local) Ok I see what you are talking about with cache's and /different/ URL structures. I don't see a benefit to having different repo structures. I think some naming guidelines (unique namespace for a Project's Repository Space) is desired. You solution does address complete repository/directory flexibility, and addresses collisions from different repositories. Personally, I don't see a benefit in this flexibility. I think some restricted structure is important. > > I think the two proposals can coexist. I think the role of metadata, > among other things, will be to resolve ids, versions to 'real' urls; at > that point maven will attempt to download the URL from /equivalent > mirrors/ for that URL, in the users order of preference; for each mirror > it tries, it will first check the cache, then download a copy to the > cache if none exists; finally the location of the file in the cache is > returned. However, I can get straight URL dependencies to work even if > the metadata doesnt exist. This definitely can coexists with the DNS portion of my proposal. However, the other part of my proposal is looking for a "standard" base structure based on groupID (namespaces based on reverse domain names). The base structure will point to the Project's Repository Space. In this there will be a default structure and naming convention as well, but this can be overridden with the presence of a meta file. > Anyway, enough. I need to put up or shut up, I'll get some coding done. Nonsense ;-) It is definitely beneficial to talk about design in plain English rather than in code. - Mike > > - Baz > > > > > > Privacy and Confidentiality Notice > > ------------------------------------------------ > > The information contained in this E-Mail message is intended only for the > person or persons to whom it is addressed. Such information is > confidential and privileged and no mistake in transmission is intended to > waive or compromise such privilege. If you have received it in error, > please destroy it and notify us on the telephone number printed above. If > you do not receive complete and legible copies, please telephone us > immediately. Any opinions expressed herein including attachments are those > of the author only. i-documentsystems Ltd. does not accept responsibility > for the accuracy or completeness of the information provided or for any > changes to this Email, however made, after it was sent. (Please note that > it is your responsibility to scan this message for viruses). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
