Stanley,Michael P. wrote:
I'm not a fan of adding path to the POM. It requires developers to haveCurrently developers have to have a knowledge of each dependencies repository space anyway. They also have to 'undo' the name munging to figure out how to create a reference to a specific jar on ibiblio. As for re-org - my point was that these things are like PURLs - you can't reorganize the past. Adding another layer of indirection doesn't get away from the fact that at /some point/ the references have to be stable, eg the referernce to the metadata for a project gets you there, or there's a searchable repo catalog in every repo thats always in the same place with the same structure. It amounts to the same thing.
knowledge of each dependencies project's repository space. It also
prevents projects from manipulating (reorganizing) their project space
without worrying about breaking anyone dependent on its resources.
Also, devs don't need to understand the structure of a repo - only where one thing is in the repo, which they can find easily by browsing. There is a difference; the current maven conventions require understanding of the structure /as well/ in order to decompose an URL into group/artifact/version parts.
I don't think this is a pro. Granted it needs to be cleaned up, andYes and no. We do need a mapping from group/artifact/version to a path, in order to install something into the repo. However when we get something back out, its not always been built with maven. The g/a/v mapping works poorly there. I'm suggesting it gets in the way.
restrictions(conventions) need to be agreed on once and for all, but I
feel that having general conventions (and restriction) w/ projected,
groupID, artifactID, version, and domain is desired.
But with URNs the developers depending on them will need to. This isn'tThat would be nice. But it only works if everyone uses the maven conventions. This is patently not the case, and is unlikely to ever be the case.
ideal. I shouldn't matter to the developers how the PRS is organized.
They just need to know I'm need this version of this project.
I've seen this DNS proposal, and I'm not keen on it at all. Being able to provide arbitrary DNS entries is a pretty high barrier to entry for someone trying to set up a repo (I'm happy enough editing zone files, but I know most sysadmins would be dead set against letting you do this)By adding the domain we can also now provide dependency providers to stand up and maintain their own repositories. Repositories that dependencies exist in can be auto discovered through DNS lookup for _mavenrepo._tcp.<domain>
- Dependency providers can move to different repositories with no fuss - With the addition of the repository meta-info they can move/reorganize PRS without screwing projects that depend on it.
After some more thought, I came up with a slight update that allows for distributed repositories. I mean to write patches to try this idea out so I'm not just shooting the breeze this time.
Dependencies
==========
All deps are specified using an URL. ie, for ant-1.4.1, you'd name it as "http://www.ibiblio.org/maven/ant/jars/ant-1.4.1.jar";.
All deps have a unique id which is used to refer to them from jelly. This is unrelated to the URL.
In the patches, I plan to do this by allowing the URL to be specified, while maintaining backwards compatibility with the current behaviour (by default I will construct an URL to your first listed remote repo, ids are constructed exactly as at present).
Local Repos
=========
There is a cache which contains downloads from remote repos. There is a different cache dir for each remote repo, so repo structure is allowed to vary.
The local repo is just that, a local repo, with no possibility of remote stuff being downloaded into it.
There is a list of remote repos which are regarded as 'local' - they are only copied into the build directly, not from the local repo (I'm thinking here of file:// repos, inside a LAN. This would allow for peer-to-peer behaviours, listing your groups local repos as remote to you, but marking them local in terms of file copying)
Remote Repos
==========
The list of remote repos becomes a list of mirrors. Actually I'd like something richer, so I can have multiple repos with different structures, each with a separate list of mirrors. Simple string matching is used to determine if a dep comes from a mirror set, and to remove the mirror prefix to obtain the relative URL.
Downloads are into a cache-per-repo. You don't get clashes from multiple remote repos. The cache is obviously checked first, except for SNAPSHOTS.
A file requested from a remote repo with no mirrors is grabbed directly from that URL. NB this allows arbitrary resources to be listed as dependencies, without them being in a maven repo at all.
Cache-per-mirror-set is /necessary/ to support multiple sets of mirrors with different structures, but isn't required if all repos have the same structure. Cache-per-repo requires less info at the point of download, so its easier to implement than cache-per-mirror-set.
Installs
=====
This is the point where maven needs to build a name which can go into a local repo, or the group repo. The rule is in a property in the jelly context, and can be overridden.
While I know you don't like the URL/URN idea, some of the key separations of concerns are surely pertinent to any maven repo redesign: the local repo and the cache are not the same thing, constructing a name for the artifact we're building is not required to name an artifact we depend on, remote repos with the same structure act like mirrors.
Anyhoo, I'm busy with project stuff for the next couple of days, but I'll try to come up with patches that do all this over the weekend. Then they can be accepted or rejected, but at least there'll be something concrete to argue about. The changes should be pretty much entirely backwards compatible, with the exception of the split of the cache from the local repo.
Cheers, 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]
