Stanley,Michael P. wrote:
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.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!)
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>
Does this stop you writing metadata for other packages? No. Does it get the project up and running faster? Yes.
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/Of course there isn't one. Indirection is a panacea. But its a panacea with a cost.
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.
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.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.
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:
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
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)
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.
Anyway, enough. I need to put up or shut up, I'll get some coding done.
- 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]
