Why is this confusing? I think people understand URI rewriting pretty well. The mvn: uri is an abstraction, and is globally invariant and abstract, while an http: url is concrete and physically exists, but is locally bound based on repository configuration.
I may get mvn://org.springframework/spring-beans/2.5.6 from http://myrepsoitory/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar while you get it from http://yourrepsoitory/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar and others may get it from http://mirrors.ibiblio.org/pub/mirrors/maven2/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar But it's all the same dependency. The convention seems to be to translating "." in the groupId into "/" and to append /${artifactId}.${version}.jar and to prepend your repository root, which could use file:// or http:// or ftp:// or gopher:// or whatever. Simple. Ralph Goers wrote: > > I'm actually surprised no one has commented on this. While I can see > the benefits it might also be confusing when you realize that > > mvn://org.springframework/spring-beans/2.5.6 > > is equivalent to > > http://myrepsoitory/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar > > Ralph > > > On May 24, 2009, at 10:22 PM, bwtaylor wrote: > >> >> I'm awaiting eagerly the Maven 3 introduction of attribute based >> POMs called >> for by MNG-3397. Still, I think a lot more can be done to improve, >> for lack >> of a better term, the fluency maven's language. >> >> One of the things that's always gnawed at me is the three separate >> attributes needed to define a dependency. Really, there is an implied >> constraint here as they relate in a hierarchical manner, but jointly >> define >> one thing. There happens to be another problem domain that has >> solved the >> idea of identifying resources universally using a single identifier, >> namely >> the internet. So here's an idea: name dependencies by URIs under a >> mvn: >> scheme. >> >> What if... >> mvn://${groupID}/${artifactId}/${version} >> meant the obvious thing. What if the following were equivalent: >> >> Maven 2: >> <dependency> >> <groupId>org.springframework</groupId> >> <artifactId>spring-beans</artifactId> >> <version>2.5.6</version> >> </dependency> >> >> Proposed Maven 3: >> <dependency uri="mvn://org.springframework/spring-beans/2.5.6"/> >> >> Similarly for archetyptes, these would be equivalent: >> >> Maven 2: >> mvn archetype:generate \ >> -DgroupId=org.sonatype.mavenbook \ >> -DartifactId=quickstart \ >> -Dversion=1.0-SNAPSHOT \ >> -DpackageName=org.sonatype.mavenbook \ >> -DarchetypeGroupId=org.apache.maven.archetypes \ >> -DarchetypeArtifactId=maven-archetype-quickstart \ >> -DarchetypeVersion=1.0 >> >> Proposed Maven 3: >> mvn archetype:generate \ >> -Duri=mvn://sonatype.mavenbook/quickstart/1.0-SNAPSHOT \ >> >> -DarchetypeUri=mvn://org.apache.maven.archetypes/maven-archetype- >> quickstart/1.0 >> \ >> -DpackageName=org.sonatype.mavenbook >> >> Thoughts? >> -- >> View this message in context: >> http://www.nabble.com/Idea%3A-maven-uri%27s-tp23701309p23701309.html >> Sent from the Maven Developers mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > -- View this message in context: http://www.nabble.com/Idea%3A-maven-uri%27s-tp23701309p23750359.html Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org