Jason van Zyl wrote:
On Tue, 2003-01-07 at 14:25, Brian Ewins wrote:Excellent. I'll read up on this, but there's an obvious question - do you still need the + notation when calling plugin.getDependencyPath()?
- there is the ugly "axis+saaj" wart to express dependencies on artifacts with 'the wrong name'You can use <groupId> and <artifactId> if you wish, we were just trying
to maintain backward compatibility with fugly +/: notation.
I do agree that the first name is better, and maven should /create/ artifacts with names like this. However, I don't agree with renaming third party artifacts to get this effect, and it seems to me that in the past some of the renaming has been even more severe (merging jars, for example), making it harder to locate the central copy of classes - but this is all in the past if the groupId/artifactId stuff works well.Naming conventions can certainly tell you something. Which is more meaningful to you:1) foo-1.0.jar 2) foo.jar
I'm very much in agreement here. Before using maven, I wrote the 'fingerprint.jsp' in Apache Axis, which tries to provide a view of what jars the user has in the classpath, in order that people can publish 'working' setups or quickly describe 'broken' setups. I tried to identify jar versions and was disappointed with the practically nonexistent information in most manifests (including Sun's jars of javax.* stuff). I ended up just printing file sizes as a guide.We can certainly move toward gleaning information from the manifest but these too currently are all over the map. We did what we could with what we had.
I don't think indirect dependencies are quite so straightforward. The obvious example is JAXP; its not just versions of a dependency, but alternatives to that dependency. [xerces-1.4.4], or [xercesImpl with xml-apis], or [none required on JDK 1.4]. It is a PITA documenting all the dependencies, but being explicit helps avoid confusion about where a jar is coming from, and allows you to omit a dependency entirely.Maven will eventually work so that all indirect dependencies will be gleaned, but if in the POM you state a version of one of those direct dependencies then the POM will be obeyed. You as a project developer will always have the choice, Maven will just try to help out.
I'm just trying to make things easier, but I'm not going to take awayI think there are conflicting goals here - 'maven should make things easy' and 'maven should promote best practice'. If you're not explicit about everything your project depends on, is your build really repeatable? On the other hand, being explicit makes it harder to get a build up and running ("just give me whatever version of xalan and xerces work together!").
rope that you could potentially hang yourself with ;-)
A suggestion: instead of letting maven automatically resolve everything, why not let the user ask maven to write its suggested dependencies into the project.xml? eg "maven dependency:guess". The newbie gets up and running quickly with something that is truly 'best practice', the user with special requirements doesn't need to learn special 'opt outs', and it doesnt matter so much if maven's guesses at what the dependencies really are are a bit off.
Anyway, thanks Jason, that was a really good reply to my bellyaching!
-Baz
Privacy and Confidentiality Notice
------------------------------------------------
The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses).
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
