On Aug 13, 2008, at 3:16 PM, David Jencks wrote:
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.
I've implemented this, see https://issues.apache.org/jira/browse/GERONIMO-4248
. I'm testing to see if the build can be done twice without failure,
then will commit the history files or fix any problems that show up.
What the new mojo does is like this (from the JIRA):
* keeps historical dependencies in src/main/history/
dependencies.xml
* if the file is missing, it creates it with current dependency
info
* if the file is there, it compares with current dependency info
and if it's changed writes out dependences.added.xml and
dependencies.removed.xml
* by default it fails on changes, although this can be turned off.
* respects current useTransitiveDependencies flag setting.
The first time it runs it can't fail. If this causes problems we
should be able to work around them by removing the history files with
find . -name dependencies.xml|xargs rm
thanks
david jencks
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
