Stanley,Michael P. wrote:
Actually, this is similar to an idea I had. Last night I was trying toCounter-proposal (just thinking aloud):
think of how to provide project-by-project customizable organization of
their repository space. Then it hit me - A meta file "repository.xml".
Specify all dependencies repository paths explicitly (really, this is defining an urn:maven: URN scheme, without bothering to specify the prefix). Specify a short name/alias for your dependency in your project.xml. ie
<dependency>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1.0</version>
<jar>some-wacky-name-1.0-is-broken.not-a-jar</jar>
</dependency>becomes:
<dependency>
<!-- id goes back to being the thing you use to refer to this thing from jelly-->
<id>foo</id>
<path>foo/jars/some-wacky-name-1.0-is-broken.not-a-jar</path>
</dependency>
This would resolve to http://www.ibiblio.org/maven/data/foo/jars/some-wacky-name-1.0-is-broken.not-a-jar
Why the extra 'data' bit? Metadata, checksums, and the like, would just use a different prefix:
http://www.ibiblio.org/maven/checksum/foo/jars/some-wacky-name-1.0-is-broken.not-a-jar
http://www.ibiblio.org/maven/metadata/foo/jars/some-wacky-name-1.0-is-broken.not-a-jar
This explains how you get to dependencies, but not how the project comes up with its /own/ URN. We do this by making the current project's naming rule explicit in your project.properties:
maven.repopath.jar=megacorp.com/funky/${pom.id}-${pom.version}.jar
or whatever. clearly projects that do want to build multiple artifacts could come up with their own naming convention, now its jellified; and the default rule that is used currently would be the default for this property.
When it comes down to it, artifact ids are being used in jelly as aliases for more complex 'constructed' names which might as well be URNs. The version numbers, for example, are never used anywhere, apart from looking for the word 'SNAPSHOT'. The paths are also currently the same no matter what kind of repo is being used. Using explicit URNs means that URI-handling code can deal with breaking down the path elements if you want. You can have domain names or reverse domain names in paths if you think these will help. Realising that aliases are just local names for dependencies means we can go back to simple ways of referring to specific dependencies from our jelly - you just use the short alias.
PROS: gets rid of groupid, artifactid, <jar>, artifact name munging rules etc etc in one fell swoop.
Your proposal kept the current layout as a way of navigating to the metadata. The URN proposal lets people organize the metadata the same as the data.PROS; - Ultimate extensibility over time (consist extension point)
- Very flexible in regards to project specific organizationURNs don't give a hoot about project organisation either.
- Still provides default layout for *most* projects, since specificProviding a default URN building rule lets people use the default layout. Providing flexible URN rules lets people do what the heck they want.
project organization is probably going to be a rare thing
The URN proposal gives repo layout flexibility (some might say "uncontrolled flexibility") without requiring the metadata facility to work yet. However I don't expect it to be adopted anytime soon as it breaks backward compatibility (its biggest CON), eg with the SNAPSHOT dependency flipping thang. It also prevents future layout reorgs, since the URNs you provide act similarly to PURLs for the resources you depend on. I don't see this as necessarily a bad thing.CONS: - Need to tread carefully as far as performance is concerned (adding xml processing to artifacts may provide a bottleneck). I do feel though that this is going to be a rare case for most projects.
As an example of how this might make life simpler, I can browse to a dep on ibiblio that I need:
http://www.ibiblio.org/maven/xerces/jars/xercesImpl-2.0.2.jar
Then add it as a dependency like so:
<dependency>
<id>xml-parser</id>
<path>xerces/jars/xercesImpl-2.0.2.jar</path>
</dependency>
... without having to figure out how to turn that back into group, artifact id, version; and then change my xml parser to crimson like so:
<dependency>
<id>xml-parser</id>
<path>crimson/jars/crimson-1.1.3.jar</path>
</dependency>
... without having to change my jelly that mentioned the "xml-parser" alias. This would be much simpler to explain to people than the current scheme ;)
Anyway, something to discuss.
-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]
