You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by bwtaylor <br...@yahoo.com> on 2009/05/25 07:22:17 UTC
Idea: maven uri's
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Ralph Goers <ra...@dslextreme.com>.
On May 27, 2009, at 10:31 PM, Peter Janes wrote:
> I was in the process of writing a similar (but much longer)
> response, but Christian's covers most of the same ground. I've only
> got two points to add.
>
> Point 1: I think it's important not to conflate identifiers with
> other attributes. In particular, "scope" and "optional" shouldn't
> be considered part of an identifier: foo:bar:1:jar is exactly the
> same thing whether it's in test scope or not. Reusing one of
> Christian's examples, you'd wind up with
>
> <dependency id="org.easymock:easymock:2.4:jar" scope="test"
> optional="false"/>
>
> (Ignoring the fact that attributes are un-Maveny, of course---since
> we're bringing up "annoying" things! Note that I've also updated
> the example slightly to use version:packaging, which is more
> sortable.)
>
> Point 2: Using URI syntax would mean you can take advantage of the
> URI facilities that exist in pretty much every language used today.
> In Java, for example, it would be easy to add a handler that would
> be applied to anything that supports URIs; you'd then be able to use
> Maven's repository resolution to retrieve resources.
>
> Peter J.
Cool. Now that we've actually had some discussion on the subject I'll
jump in with how I really feel.
First, there are definitely some aspects to this that I like. I
definitely would prefer the shorter syntax when having to enter it on
a command line.
OTOH, in the pom I would really prefer the attribute syntax Brett
demonstrated quite a while ago. It shortened the pom considerably.
IIRC, doesn't the Maven 3 work abstract out the pom processing so that
pretty much any syntax can be used? While I like the flexibility of
that, having everybody and their brother create their own syntax would
be a disaster.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Peter Janes <ma...@peterjanes.ca>.
I was in the process of writing a similar (but much longer) response, but
Christian's covers most of the same ground. I've only got two points to add.
Point 1: I think it's important not to conflate identifiers with other
attributes. In particular, "scope" and "optional" shouldn't be considered
part of an identifier: foo:bar:1:jar is exactly the same thing whether it's in
test scope or not. Reusing one of Christian's examples, you'd wind up with
<dependency id="org.easymock:easymock:2.4:jar" scope="test" optional="false"/>
(Ignoring the fact that attributes are un-Maveny, of course---since we're
bringing up "annoying" things! Note that I've also updated the example
slightly to use version:packaging, which is more sortable.)
Point 2: Using URI syntax would mean you can take advantage of the URI
facilities that exist in pretty much every language used today. In Java, for
example, it would be easy to add a handler that would be applied to anything
that supports URIs; you'd then be able to use Maven's repository resolution to
retrieve resources.
Peter J.
On 27/05/09 11:58 PM, Christian Edward Gruber wrote:
> Fair comment. Not less annoying. It's less size (not bytes, but actual
> typing... and to Brett's point, in Eclipse, I would be typing in a form,
> not the raw pom.xml file, so it'd be the same regardless of how it's
> represented in the pom.
>
> Having said that, the ?params annoy me too, but I was responding to the
> argument that it was non-deterministic to reverse-engineer. That was
> simply untrue. And there might be less annoying approaches.
>
> Frankly, I'm just as happy with
> groupId:artifactId:packaging:version:scope. You could even have a
> collapse-order, so you can make terser expressions (which I think is the
> case now). I just want a clean, easy to human-read, not annoying to
> type approach, ideally that only takes one line. So I can read large
> batches of them in one glance, instead of having to scroll of the screen.
>
> Are these dealbreakers? No. But they're slightly less annoying to me
> than XML.
>
> Christian.
>
> P.S. Example of the above. Really really easy to read. Easy to sort,
>
> <project>
> <modelVersion>5.0.0</modelVersion>
> <parent id="my.project:my-parent:1.5" />
> <artifact id=":my-artifact-id:" /> <!-- inherits null entries from
> parent -->
> <packaging>war</packaging>
> <dependencies>
> <dependency id="org.springframework:spring-beans:2.5" />
> <dependency id="org.springframework:spring-something-other:2.5" />
> <dependency id="net.blah:blah-framework:3.3" />
> <dependency id="my.project:my-project-flash-application:swf:1.5" />
> <dependency id="org.easymock:easymock::2.4:test" /> <!-- jar is
> default -->
> </dependencies>
> </project>
>
>
>
> On 27-May-09, at 23:35 , Brian Fox wrote:
>
>> That's less annoying than the current format? Not to me that's for sure.
>>
>> On Wed, May 27, 2009 at 7:28 PM, Christian Edward Gruber <
>> christianedwardgruber@gmail.com> wrote:
>>
>>> I'm not sure how that pans out.
>>>
>>>
>>> mvn://net.israfil.foundation/foundation-container/1.1?optional&packaging=pom&scope=test
>>>
>>>
>>> Done.
>>>
>>> And there's no issue with reverse engineering. The "host" is the
>>> groupid,
>>> the first folder is the artifact, the last item is the version, and the
>>> supplemental attributes are uri parameters. (maybe there's a terser
>>> wya to
>>> do that, but it's the best I can think of off-hand.) There's nothing
>>> ambiguous there, is there? It's also extensible.
>>>
>>> cheers,
>>> Christian.
>>>
>>>
>>> On 27-May-09, at 22:24 , Brian Fox wrote:
>>>
>>> The problem with this is two-fold actually,
>>>> The url representation currently doesn't encapsulate the other parts of
>>>> the
>>>> dependency declaration like optional or scope. Further, it is
>>>> difficult to
>>>> deterministically reverse a url like that back to the GAV
>>>> components... we
>>>> struggle with this often in Nexus when people have unusual artifact or
>>>> group
>>>> ids that make it hard for example to separate the group from the
>>>> artifact,
>>>> or the version from the classifier.
>>>>
>>>> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans <jorg.heymans@gmail.com
>>>>> wrote:
>>>>
>>>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>>>>> <ch...@gmail.com> wrote:
>>>>>
>>>>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those
>>>>>> work
>>>>>> for me.
>>>>>>
>>>>>
>>>>> My thoughts exactly !
>>>>>
>>>>> Jorg
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>> Christian Edward Gruber
>>> e-mail: christianedwardgruber@gmail.com
>>> weblog: http://www.geekinasuit.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Christian Edward Gruber <ch...@gmail.com>.
Fair comment. Not less annoying. It's less size (not bytes, but
actual typing... and to Brett's point, in Eclipse, I would be typing
in a form, not the raw pom.xml file, so it'd be the same regardless of
how it's represented in the pom.
Having said that, the ?params annoy me too, but I was responding to
the argument that it was non-deterministic to reverse-engineer. That
was simply untrue. And there might be less annoying approaches.
Frankly, I'm just as happy with
groupId:artifactId:packaging:version:scope. You could even have a
collapse-order, so you can make terser expressions (which I think is
the case now). I just want a clean, easy to human-read, not annoying
to type approach, ideally that only takes one line. So I can read
large batches of them in one glance, instead of having to scroll of
the screen.
Are these dealbreakers? No. But they're slightly less annoying to me
than XML.
Christian.
P.S. Example of the above. Really really easy to read. Easy to sort,
<project>
<modelVersion>5.0.0</modelVersion>
<parent id="my.project:my-parent:1.5" />
<artifact id=":my-artifact-id:" /> <!-- inherits null entries
from parent -->
<packaging>war</packaging>
<dependencies>
<dependency id="org.springframework:spring-beans:2.5" />
<dependency id="org.springframework:spring-something-other:
2.5" />
<dependency id="net.blah:blah-framework:3.3" />
<dependency id="my.project:my-project-flash-application:swf:
1.5" />
<dependency id="org.easymock:easymock::2.4:test" /> <!-- jar
is default -->
</dependencies>
</project>
On 27-May-09, at 23:35 , Brian Fox wrote:
> That's less annoying than the current format? Not to me that's for
> sure.
>
> On Wed, May 27, 2009 at 7:28 PM, Christian Edward Gruber <
> christianedwardgruber@gmail.com> wrote:
>
>> I'm not sure how that pans out.
>>
>>
>> mvn://net.israfil.foundation/foundation-container/1.1?
>> optional&packaging=pom&scope=test
>>
>> Done.
>>
>> And there's no issue with reverse engineering. The "host" is the
>> groupid,
>> the first folder is the artifact, the last item is the version, and
>> the
>> supplemental attributes are uri parameters. (maybe there's a terser
>> wya to
>> do that, but it's the best I can think of off-hand.) There's nothing
>> ambiguous there, is there? It's also extensible.
>>
>> cheers,
>> Christian.
>>
>>
>> On 27-May-09, at 22:24 , Brian Fox wrote:
>>
>> The problem with this is two-fold actually,
>>> The url representation currently doesn't encapsulate the other
>>> parts of
>>> the
>>> dependency declaration like optional or scope. Further, it is
>>> difficult to
>>> deterministically reverse a url like that back to the GAV
>>> components... we
>>> struggle with this often in Nexus when people have unusual
>>> artifact or
>>> group
>>> ids that make it hard for example to separate the group from the
>>> artifact,
>>> or the version from the classifier.
>>>
>>> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans
>>> <jorg.heymans@gmail.com
>>>> wrote:
>>>
>>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>>>> <ch...@gmail.com> wrote:
>>>>
>>>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse.
>>>> Those
>>>>> work
>>>>> for me.
>>>>>
>>>>
>>>> My thoughts exactly !
>>>>
>>>> Jorg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>> Christian Edward Gruber
>> e-mail: christianedwardgruber@gmail.com
>> weblog: http://www.geekinasuit.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Brian Fox <br...@infinity.nu>.
That's less annoying than the current format? Not to me that's for sure.
On Wed, May 27, 2009 at 7:28 PM, Christian Edward Gruber <
christianedwardgruber@gmail.com> wrote:
> I'm not sure how that pans out.
>
>
> mvn://net.israfil.foundation/foundation-container/1.1?optional&packaging=pom&scope=test
>
> Done.
>
> And there's no issue with reverse engineering. The "host" is the groupid,
> the first folder is the artifact, the last item is the version, and the
> supplemental attributes are uri parameters. (maybe there's a terser wya to
> do that, but it's the best I can think of off-hand.) There's nothing
> ambiguous there, is there? It's also extensible.
>
> cheers,
> Christian.
>
>
> On 27-May-09, at 22:24 , Brian Fox wrote:
>
> The problem with this is two-fold actually,
>> The url representation currently doesn't encapsulate the other parts of
>> the
>> dependency declaration like optional or scope. Further, it is difficult to
>> deterministically reverse a url like that back to the GAV components... we
>> struggle with this often in Nexus when people have unusual artifact or
>> group
>> ids that make it hard for example to separate the group from the artifact,
>> or the version from the classifier.
>>
>> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans <jorg.heymans@gmail.com
>> >wrote:
>>
>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>>> <ch...@gmail.com> wrote:
>>>
>>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those
>>>> work
>>>> for me.
>>>>
>>>
>>> My thoughts exactly !
>>>
>>> Jorg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Idea: maven uri's
Posted by Christian Edward Gruber <ch...@gmail.com>.
I'm not sure how that pans out.
mvn://net.israfil.foundation/foundation-container/1.1?
optional&packaging=pom&scope=test
Done.
And there's no issue with reverse engineering. The "host" is the
groupid, the first folder is the artifact, the last item is the
version, and the supplemental attributes are uri parameters. (maybe
there's a terser wya to do that, but it's the best I can think of off-
hand.) There's nothing ambiguous there, is there? It's also
extensible.
cheers,
Christian.
On 27-May-09, at 22:24 , Brian Fox wrote:
> The problem with this is two-fold actually,
> The url representation currently doesn't encapsulate the other parts
> of the
> dependency declaration like optional or scope. Further, it is
> difficult to
> deterministically reverse a url like that back to the GAV
> components... we
> struggle with this often in Nexus when people have unusual artifact
> or group
> ids that make it hard for example to separate the group from the
> artifact,
> or the version from the classifier.
>
> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans
> <jo...@gmail.com>wrote:
>
>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>> <ch...@gmail.com> wrote:
>>
>>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse.
>>> Those work
>>> for me.
>>
>> My thoughts exactly !
>>
>> Jorg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by bwtaylor <br...@yahoo.com>.
As far as not including optional/scope: The way I formulated it, no they
aren't included. So? Why should they be: those aren't attributes of the
resource itself, but in how it is used. What's wrong with using the existing
way of configuring those? But if they need to be included, then include them
as URI parameters.
As far as "unusual" artifact or group ids: don't allow them. Nobody can
reasonably complain about having to follow the constraints imposed by the
URI format. Convention over configuration requires, benefits from, and
improves with rigid conventions being enforced. Though it's hard for me to
envision what exactly is being given up without an example. Are people using
"/" or " " in their Ids? If so, will anyone shed a tear if this is
disallowed? Or allow it the way the internet does: %20 for space.
And I'd think preventing through convention the problems you describe Nexus
is experiencing would be another added benefit here that you would support.
BRIAN FOX-5 wrote:
>
> The problem with this is two-fold actually,
> The url representation currently doesn't encapsulate the other parts of
> the
> dependency declaration like optional or scope. Further, it is difficult to
> deterministically reverse a url like that back to the GAV components... we
> struggle with this often in Nexus when people have unusual artifact or
> group
> ids that make it hard for example to separate the group from the artifact,
> or the version from the classifier.
>
> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans
> <jo...@gmail.com>wrote:
>
>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>> <ch...@gmail.com> wrote:
>>
>> > Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those
>> work
>> > for me.
>>
>> My thoughts exactly !
>>
>> Jorg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Idea%3A-maven-uri%27s-tp23701309p23763577.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Brett Porter <br...@apache.org>.
You've also just lost decent autocomplete in IDEs, etc.
I think the URIs make sense for when you're in a context where such a
thing might make sense (the PAX / ServiceMix Kernel example comes to
mind), but to force people to mentally translate a model to a URI when
they are thinking in terms of separate pieces is unnecessary just to
save a few bytes.
- Brett
On 28/05/2009, at 12:24 PM, Brian Fox wrote:
> The problem with this is two-fold actually,
> The url representation currently doesn't encapsulate the other parts
> of the
> dependency declaration like optional or scope. Further, it is
> difficult to
> deterministically reverse a url like that back to the GAV
> components... we
> struggle with this often in Nexus when people have unusual artifact
> or group
> ids that make it hard for example to separate the group from the
> artifact,
> or the version from the classifier.
>
> On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans
> <jo...@gmail.com>wrote:
>
>> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
>> <ch...@gmail.com> wrote:
>>
>>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse.
>>> Those work
>>> for me.
>>
>> My thoughts exactly !
>>
>> Jorg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Brian Fox <br...@infinity.nu>.
The problem with this is two-fold actually,
The url representation currently doesn't encapsulate the other parts of the
dependency declaration like optional or scope. Further, it is difficult to
deterministically reverse a url like that back to the GAV components... we
struggle with this often in Nexus when people have unusual artifact or group
ids that make it hard for example to separate the group from the artifact,
or the version from the classifier.
On Wed, May 27, 2009 at 2:06 PM, Jorg Heymans <jo...@gmail.com>wrote:
> On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
> <ch...@gmail.com> wrote:
>
> > Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those work
> > for me.
>
> My thoughts exactly !
>
> Jorg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Idea: maven uri's
Posted by Jorg Heymans <jo...@gmail.com>.
On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
<ch...@gmail.com> wrote:
> Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those work
> for me.
My thoughts exactly !
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Alin Dreghiciu <ad...@gmail.com>.
Yep, that was my first try: to convince SpringSource guys that an harcoded
looky in ~/m2/repository is not enough. Then I started the above mentioned
handler.
On Wed, May 27, 2009 at 6:22 PM, Peter Janes <maven.apache.org@peterjanes.ca
> wrote:
> Looks like this has been considered before (and implemented):
>
> Maven URL handler implements the specs from OSGi URl Handlers Service and
>> registers a service that handles url's as:
>>
>> mvn://repository/groupId/artifactId/version/type?instructions
>>
>> Where:
>>
>> * repository - is the repostory from where the artifact to be
>> downloaded.If values is localrepo it means that the value is from the local
>> repository on the machine osgi evevironment is running
>>
>
> http://groups.google.com/group/spring-osgi/web/maven-url-handler
>
> It seems to dovetail with the OSGi strategy that's been mentioned on this
> list, too.
>
>
>
> Christian Edward Gruber wrote:
>
>> Untrue. It can resolve to that, but it resolves to only the latter part,
>> without the repository reference.
>>
>> Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those work
>> for me.
>>
>> Christian.
>>
>> On 27-May-09, at 03:22 , 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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> Christian Edward Gruber
>> e-mail: christianedwardgruber@gmail.com
>> weblog: http://www.geekinasuit.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> --
> Sometimes the Universe needs a change of perspective.
> --J. Michael Straczynski
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: Idea: maven uri's
Posted by Peter Janes <ma...@peterjanes.ca>.
Looks like this has been considered before (and implemented):
> Maven URL handler implements the specs from OSGi URl Handlers Service and registers a service that handles url's as:
>
> mvn://repository/groupId/artifactId/version/type?instructions
>
> Where:
>
> * repository - is the repostory from where the artifact to be downloaded.If values is localrepo it means that the value is from the local repository on the machine osgi evevironment is running
http://groups.google.com/group/spring-osgi/web/maven-url-handler
It seems to dovetail with the OSGi strategy that's been mentioned on this
list, too.
Christian Edward Gruber wrote:
> Untrue. It can resolve to that, but it resolves to only the latter part,
> without the repository reference.
>
> Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those
> work for me.
>
> Christian.
>
> On 27-May-09, at 03:22 , 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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Christian Edward Gruber <ch...@gmail.com>.
Untrue. It can resolve to that, but it resolves to only the latter
part, without the repository reference.
Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those
work for me.
Christian.
On 27-May-09, at 03:22 , 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Alin Dreghiciu <ad...@gmail.com>.
In OPS4J Pax URL = a set of OSGi url handlers that can be used as well
outside an OSGi container, we have using very successfully such urls:
http://wiki.ops4j.org//x/CoA6This is a "home grown" implementation (version
resolution, downloading, ...) as by the time it was made it was awful to
embed maven. Now I'm working on another implementation that is based on
Mercury.
On Wed, May 27, 2009 at 10:22 AM, Ralph Goers <ra...@dslextreme.com>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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: Idea: maven uri's
Posted by bwtaylor <br...@yahoo.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Idea: maven uri's
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org