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
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
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 consider
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 wa
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 <
christianedwardgru...@gmail.com> wrote:
> I'm not sure how that pans out.
>
>
> mvn://net.israfil.foundation/foundation-container/1.1?optional&packaging=pom&scope=te
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 term
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 at
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 N
On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber
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-unsubscr...@maven.a
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 wrote:
> Looks like this has been considered before (and implemented):
>
> Maven URL handle
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/spr
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
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 o
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 mav
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 2
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
16 matches
Mail list logo
