On Wed, Aug 13, 2008 at 2:23 AM, David Jencks <[EMAIL PROTECTED]> wrote: > > I'm suggesting 2 things: > 1. fix our dependencies so they are correct. This, by itself, will make > useTransitiveDependencies=true work properly. Any problems such as unwanted > inclusions are bugs that have a good chance of producing highly undesirable > behavior in maven if they haven't already done so. > 2. make the build-time classpath match the run-time classpath by using the > cars to aggregate their dependencies in maven, just like they do in the > running geronimo server. This should dramatically reduce the number of > dependencies in most of the plugin poms.
I agree that we should fix our DM so that build-time classpath matches the run-time classpath, however, the reality is that no one really maintains the DM. Things get very quickly out of date and we might end up pulling in stuff into server that we don't really need. My guess is that if we go ahead with the transitive dependencies a few days before the next release somebody will realize that the DM is messed up and try to fix it which will cause build or maybe even runtime errors. The point is that if we go ahead with the transitive deps we must pay much better attention to the DM and/or have better tools to catch the problems in the DM early. Btw, does Maven support artifact substitution? E.g. substitute commons-logging-api with jcl104-over-slf4j or javax.activation with geronimo-activation_1.1_spec, etc.? Won't this also make the DM grow overall (even if we split it among the modules)? For example, virtually every library has a dependency on commons-logging or commons-logging-api so we will need to add an exclusion to each library. Jarek
