standardized Maven GAV URN?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

standardized Maven GAV URN?

lukewpatterson
It would be nice to be able to represent any Maven GAV in a string.  Does such a standard exist?

A good use case is for plugins that allow input configuration file paths.  If there was a reusable component that took an ArtifactResolver and a String, then any plugins that currently accept file locations as Strings could passively add GAV capability.

e.g. with Clover plugin, I can give the path for the license file, but if I want to store the license in the company's internal Maven repo (and thus get the advantage of Maven versioning), I have to jump through some dependency plugin hoops to get it in the right place at the right time.  I'd like to be able to just give the Clover plugin a GAV URN and have it download what it needs

Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

Brian Fox-2
Group:artifact:version:classifier:extension is pretty common


On Jun 26, 2010, at 1:39 PM, lukewpatterson <[hidden email]> wrote:

>
> It would be nice to be able to represent any Maven GAV in a string.  Does
> such a standard exist?
>
> A good use case is for plugins that allow input configuration file paths.
> If there was a reusable component that took an ArtifactResolver and a
> String, then any plugins that currently accept file locations as Strings
> could passively add GAV capability.
>
> e.g. with Clover plugin, I can give the path for the license file, but if I
> want to store the license in the company's internal Maven repo (and thus get
> the advantage of Maven versioning), I have to jump through some dependency
> plugin hoops to get it in the right place at the right time.  I'd like to be
> able to just give the Clover plugin a GAV URN and have it download what it
> needs
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

nicolas de loof-2
is le last part "type" or "packaging" ?

2010/6/29 Brian Fox <[hidden email]>

> Group:artifact:version:classifier:extension is pretty common
>
>
> On Jun 26, 2010, at 1:39 PM, lukewpatterson <[hidden email]>
> wrote:
>
> >
> > It would be nice to be able to represent any Maven GAV in a string.  Does
> > such a standard exist?
> >
> > A good use case is for plugins that allow input configuration file paths.
> > If there was a reusable component that took an ArtifactResolver and a
> > String, then any plugins that currently accept file locations as Strings
> > could passively add GAV capability.
> >
> > e.g. with Clover plugin, I can give the path for the license file, but if
> I
> > want to store the license in the company's internal Maven repo (and thus
> get
> > the advantage of Maven versioning), I have to jump through some
> dependency
> > plugin hoops to get it in the right place at the right time.  I'd like to
> be
> > able to just give the Clover plugin a GAV URN and have it download what
> it
> > needs
> >
> >
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

jochen-2
On Tue, Jun 29, 2010 at 8:34 AM, nicolas de loof
<[hidden email]> wrote:

> is le last part "type" or "packaging" ?

Is there a difference?

--
Germanys national anthem is the most boring in the world - how telling!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

nicolas de loof-2
sorry, I mean packaging vs extension.
"ejb" packaging creates a "jar" extension

2010/6/29 Jochen Wiedmann <[hidden email]>

> On Tue, Jun 29, 2010 at 8:34 AM, nicolas de loof
> <[hidden email]> wrote:
>
> > is le last part "type" or "packaging" ?
>
> Is there a difference?
>
> --
> Germanys national anthem is the most boring in the world - how telling!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

RE: standardized Maven GAV URN?

Stan Devitt-2
In reply to this post by Brian Fox-2
Why would the recommended format here be different than the format used by the dependency plugin?

(e.g.  junit:junit:jar:3.8.1:test )

Stan



-----Original Message-----
From: Brian Fox [mailto:[hidden email]]
Sent: Monday, June 28, 2010 9:56 PM
To: Maven Users List
Subject: Re: standardized Maven GAV URN?

Group:artifact:version:classifier:extension is pretty common


On Jun 26, 2010, at 1:39 PM, lukewpatterson <[hidden email]> wrote:

>
> It would be nice to be able to represent any Maven GAV in a string.  Does
> such a standard exist?
>
> A good use case is for plugins that allow input configuration file paths.
> If there was a reusable component that took an ArtifactResolver and a
> String, then any plugins that currently accept file locations as Strings
> could passively add GAV capability.
>
> e.g. with Clover plugin, I can give the path for the license file, but if I
> want to store the license in the company's internal Maven repo (and thus get
> the advantage of Maven versioning), I have to jump through some dependency
> plugin hoops to get it in the right place at the right time.  I'd like to be
> able to just give the Clover plugin a GAV URN and have it download what it
> needs
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: standardized Maven GAV URN?

lukewpatterson
Stan Devitt-2 wrote
Why would the recommended format here be different than the format used by the dependency plugin?
(e.g.  junit:junit:jar:3.8.1:test )
I was looking more for a URN for Maven coordinates, which is slightly different than the flattened form of <dependency> elements.  e.g. the <scope> portion isn't part of what I'm looking for, it is more a statement of how I rely upon it

Brian Fox-3 wrote
Group:artifact:version:classifier:extension is pretty common
I'm trying to wrap my mind around the differences and pros/cons of that vs. a format listed in the Maven docs[1]

groupId:artifactId:packaging:classifier:version

The format Brian listed seems to work better when some portions are optional.

so maybe urn:maven:groupId:artifactId:version:classifier:extension ?

[1] http://maven.apache.org/pom.html#Maven_Coordinates
Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

stephenconnolly
is : valid within a urn?

On 30 June 2010 13:34, lukewpatterson <[hidden email]> wrote:

>
>
> Stan Devitt-2 wrote:
> >
> > Why would the recommended format here be different than the format used
> by
> > the dependency plugin?
> > (e.g.  junit:junit:jar:3.8.1:test )
> >
>
> I was looking more for a URN for Maven coordinates, which is slightly
> different than the flattened form of <dependency> elements.  e.g. the
> <scope> portion isn't part of what I'm looking for, it is more a statement
> of how I rely upon it
>
>
> Brian Fox-3 wrote:
> >
> > Group:artifact:version:classifier:extension is pretty common
> >
>
> I'm trying to wrap my mind around the differences and pros/cons of that vs.
> a format listed in the Maven docs[1]
>
> groupId:artifactId:packaging:classifier:version
>
> The format Brian listed seems to work better when some portions are
> optional.
>
> so maybe urn:maven:groupId:artifactId:version:classifier:extension ?
>
> [1] http://maven.apache.org/pom.html#Maven_Coordinates
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p512112.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

justinedelson
On 6/30/10 8:42 AM, Stephen Connolly wrote:
> is : valid within a urn?
Yes.

>
> On 30 June 2010 13:34, lukewpatterson <[hidden email]> wrote:
>
>>
>>
>> Stan Devitt-2 wrote:
>>>
>>> Why would the recommended format here be different than the format used
>> by
>>> the dependency plugin?
>>> (e.g.  junit:junit:jar:3.8.1:test )
>>>
>>
>> I was looking more for a URN for Maven coordinates, which is slightly
>> different than the flattened form of <dependency> elements.  e.g. the
>> <scope> portion isn't part of what I'm looking for, it is more a statement
>> of how I rely upon it
>>
>>
>> Brian Fox-3 wrote:
>>>
>>> Group:artifact:version:classifier:extension is pretty common
>>>
>>
>> I'm trying to wrap my mind around the differences and pros/cons of that vs.
>> a format listed in the Maven docs[1]
>>
>> groupId:artifactId:packaging:classifier:version
>>
>> The format Brian listed seems to work better when some portions are
>> optional.
>>
>> so maybe urn:maven:groupId:artifactId:version:classifier:extension ?
>>
>> [1] http://maven.apache.org/pom.html#Maven_Coordinates
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p512112.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

Andreas Sewe-2
In reply to this post by lukewpatterson
Luke,

are you aiming at IANA registration of the namespace identifier? (If
not, please use a x- prefix to mark the NID as experimental:
<http://tools.ietf.org/html/rfc3406#section-3.1>.)

Best wishes,

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: standardized Maven GAV URN?

Brian Fox-2
In reply to this post by nicolas de loof-2
Neither, it's extension.

Type, packaging and extension are often the same but not always. Type
sources actually means classifier sources and extension jar for
example. Packaging maven-plugin actually means extension jar.

Sent from my iPad

On Jun 29, 2010, at 2:34 AM, nicolas de loof <[hidden email]> wrote:

> is le last part "type" or "packaging" ?
>
> 2010/6/29 Brian Fox <[hidden email]>
>
>> Group:artifact:version:classifier:extension is pretty common
>>
>>
>> On Jun 26, 2010, at 1:39 PM, lukewpatterson <[hidden email]>
>> wrote:
>>
>>>
>>> It would be nice to be able to represent any Maven GAV in a string.  Does
>>> such a standard exist?
>>>
>>> A good use case is for plugins that allow input configuration file paths.
>>> If there was a reusable component that took an ArtifactResolver and a
>>> String, then any plugins that currently accept file locations as Strings
>>> could passively add GAV capability.
>>>
>>> e.g. with Clover plugin, I can give the path for the license file, but if
>> I
>>> want to store the license in the company's internal Maven repo (and thus
>> get
>>> the advantage of Maven versioning), I have to jump through some
>> dependency
>>> plugin hoops to get it in the right place at the right time.  I'd like to
>> be
>>> able to just give the Clover plugin a GAV URN and have it download what
>> it
>>> needs
>>>
>>>
>>> --
>>> View this message in context:
>> http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: standardized Maven GAV URN?

Stan Devitt-2
In reply to this post by lukewpatterson
Such a notation would be much more useful if it were

        1. standardized and
        2. unambiguous

My personal preference would be "something like"

        groupId:artifactId(classifier):version;extension[scope]

This way, the classifier, the extension, and the scope could be optional simplifying this to

        groupId:artifactId:version    (defaulting to no classifier, extension=jar, scope=compile)

Examples:

        junit:junit:3.8.1
        junit:junit():3.8.1
        junit:junit:3.8.1;jar
        junit:junit:3.8.1;[compile]
        junit:junit:3.8.1;jar[compile]
        junit:junit():3.8.1;jar[compile]

Whatever is done, having multiple conflicting ambiguous versions of this is just bad design.  The final choice should probably be consistent with the URI specification http://labs.apache.org/webarch/uri/rfc/rfc3986.html   (in this case, a path with scheme=GAV, a blank authority, and no query or fragment)  .  It should be registered.

        i.e., GAV:junit:junit:3.8.1

Stan

PS.  The full set of coordinates falls into two categories:

        1. name the artifact  (group,artifact,version,classifier)
        2. meta-data about the artifact
                - assistance to help find it in a repo  (extension)
                - restrict its use  (scope)

Here, I have deliberately separated (1) from (2) by a ";"

> Luke Patterson wrote:
> I was looking more for a URN for Maven coordinates, which is slightly
> different than the flattened form of <dependency> elements.  e.g. the
> <scope> portion isn't part of what I'm looking for, it is more a statement
> of how I rely upon it

>> Brian Fox-3 wrote:
>> Group:artifact:version:classifier:extension is pretty common
>>



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]