On Aug 13, 2008, at 12:57 PM, Jarek Gawor wrote:
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.
I suspect that we have this kind of problems today and don't know
about them and also think that for the most part the reason we don't
have more such problems is that I've made most of the dependency
changes in all the plugin poms. This is too much for me to keep
doing; we need a better system. IMO relying more on maven
dependencies is the first step.
Using maven dependency:analyze on framework modules is proving rather
interesting and showing up some surprises. I think this might make
the module poms reasonably accurate.
For plugins, I had an idea that might help. We could have a mojo in c-
m-p come up with a list of dependencies for the geronimo-plugin.xml
and optionally save it in a file which we would commit to svn. In any
case it would compare the current file with the existing file and if
there is a difference either fail or emit a loud warning. If you want
to change the output dependencies you'd have to update the file in svn.
Anyone have any other ideas?
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.
I don't know of such a feature
thanks
david jencks
Jarek
