RE: standardized Maven GAV URN?
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: standardized Maven GAV URN?
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:bri...@infinity.nu] 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 lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: standardized Maven GAV URN?
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
is : valid within a urn? On 30 June 2010 13:34, lukewpatterson lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
On 6/30/10 8:42 AM, Stephen Connolly wrote: is : valid within a urn? Yes. On 30 June 2010 13:34, lukewpatterson lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
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 nicolas.del...@gmail.com wrote: is le last part type or packaging ? 2010/6/29 Brian Fox bri...@infinity.nu Group:artifact:version:classifier:extension is pretty common On Jun 26, 2010, at 1:39 PM, lukewpatterson lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
is le last part type or packaging ? 2010/6/29 Brian Fox bri...@infinity.nu Group:artifact:version:classifier:extension is pretty common On Jun 26, 2010, at 1:39 PM, lukewpatterson lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
On Tue, Jun 29, 2010 at 8:34 AM, nicolas de loof nicolas.del...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
sorry, I mean packaging vs extension. ejb packaging creates a jar extension 2010/6/29 Jochen Wiedmann jochen.wiedm...@gmail.com On Tue, Jun 29, 2010 at 8:34 AM, nicolas de loof nicolas.del...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
Group:artifact:version:classifier:extension is pretty common On Jun 26, 2010, at 1:39 PM, lukewpatterson lukewpatter...@gmail.com 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
standardized Maven GAV URN?
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
