hi brett, i agree for your case, that transitivity is not a must. but i do not think it would harm (except you probably end up auto-downloading additional libraries you do would not need for compilation).
maybe the reason for why i like it shoul be transitive is, that i still hope dependency mechanism could be extendet to support shared libraries. i consider beeing independent of foreign products jar-file policy (deletions, additions, renames) a big advantage. usually this is elegantly solved with a shared "library", containing a few files. may i use java itself as an example: java13-shared-lib: * jre/lib/i18n.jar * jre/lib/sunrsasign.jar * jre/lib/javaplugin.jar * jre/lib/rt.jar java14-shared-lib (there are some renames, some additions): * jre/lib/sunrsasign.jar * jre/lib/plugin.jar * jre/lib/rt.jar * jre/lib/jsse.jar * jre/lib/charsets.jar * jre/lib/jce.jar * jre/lib/ext/dnsns.jar * jre/lib/ext/sunjce_provider.jar * jre/lib/ext/ldapsec.jar * jre/lib/ext/localedata.jar java15-shared-lib: * mostly the same, but ldapsec missing, and sunpkcs11 added what we try to do is just include ONE dependency in the pom: java-shared-lib, v 1.4.2, provided (no jar attached to that one). what we expect m2 to do then if we build a war: * use all the jars depending on that dependency for compiling (i.e. transitive becomes a must) * deliver no jar, as it is provided at the target as shared library if we later switch to jdk-1.5, we just change the version number of that one dependency to 1.5.0, and everything works as before. if our code does not compile and we want to take back the upgrade, we can easily change the version number back. with the current mechanism we end up turning the whole pom upside down. a similar configuration does exist in a lot of products, like servlet and jsp api (tomcat split a single jar in v4.x to two jars in 5.x). -solo. On 7/21/05, Brett Porter <[EMAIL PROTECTED]> wrote: > only the "provided" scope dependencies are not transitive, as they are > designed for placing in an end POM. > > Consider servlet API: when you depend on it in your WAR, scope = > provided as it is used for compilation but is provided at runtime by the > container. > > Now if a library uses servlet API, provided doesn't make sense as the > library doesn't know its runtime context. This is why provided is not > transitive. The library would declare it as compile in this case, and a > WAR would then restate it as "provided" using dependency management. > > Do others agree this is the expected behaviour? > > Cheers, > Brett > > solo turn wrote: > > >but this is not transitive? i.e. you define a shared library in idea, > >eclipse, etc. with a name, containing one or more jars. if you do that > >in a pom by specifying a dependency to a library, which depends on 2 > >or more jars, how do these jars get into the compile classpath? > > > >On 7/20/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > see "provided" on that page. > > > > solo turn wrote: > > > > >hi, > > > > >how shared libraries are handled by the maven dependency management, > > >with respect to the following areas: > > >* compile: > > >seems to be perfect > > >* eclipse (create an eclipse project referencing libraries) > > >not sure, but works > > >* install (build a war, ear) > > >i have no idea how to declare a dependency as > > >"shared library" so it does not get included in the deliverable > > > > >could you please explain how you specify "shared libraries" in the pom > > >file, so they do not get inlcuded when building a war? maybe on > > >http://maven.apache.org/maven2/dependencies.html. > > > > >-solo > > > > >--------------------------------------------------------------------- > > >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] > > > > >--------------------------------------------------------------------- > >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
