On 19/03/2008, James Carman <[EMAIL PROTECTED]> wrote: > On 3/18/08, sebb <[EMAIL PROTECTED]> wrote: > > > > The groupId/artifactId/version/classifier are all necessary for > > > determining exactly which jar you're talking about. I don't think any > > > of those should be dropped. > > > > > > > > > I've yet to see anything other than "-" as a Classifier - what purpose > > does it serve? > > > > > The classifier is just not specified in those cases. There are times > when a classifier is used. Take TestNG for example. > > http://repo1.maven.org/maven2/org/testng/testng/5.7/ > > They have two different flavors jdk14 and jdk15 which are specified > using classifiers. > > > > As I can tell, the group id is not relevant to non-Maven users, and > > people who do use Maven don't need it because Maven takes care of it. > > > > > If someone wants to exclude a transitive dependency for some reason > (the transitive dependency is spring.jar and your project uses > spring-*.jars), then they need to know what the groupIds are in order > to construct the excludes. > > > > If the additional columns are to mean anything useful to the user, > > then there should be a link to a description of the column headings. > > > > > Agreed, there should be an explanation to the non-maven user, but then > again *everyone* should be using Maven anyway! ;-) > > > > Also, for anyone who is not using Maven, the M1 listing is much easier > > to use, because it gives a link to the project web-site. > > > > > Yes, the URL is nice. If you scroll down to the "Dependency Listings" > section, it has more information about each of the dependencies, > including the URL, description, and license.
But it's not easy to read; and does not appear to be in any particular order. Also has several errors, e.g. http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/ and http://xml.apache.org/commons/#external (Niall's version only) > I never noticed it > before, but way down at the bottom of the m2 report, it gives you > specific information about the dependencies like how big the jar is > and if it was compiled with debug on. That's pretty cool. As a AFAIK, that's only generated by Niall's private version... > matter of fact, maybe our jars should be compiled in "release" mode by > default, but we include the "debug" version and use a classifier to > distinguish between them? Release-compiled code performs better from > what I understand (or at least they used to). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
