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

Reply via email to