On Aug 19, 2008, at 12:27 PM, Jarek Gawor wrote:
David,
I'm confused about something. Let's take framework/configs/j2ee-system
as an example. Its pom.xml defines a dependency on:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</dependency>
The pom.xml of slf4j-log4j12 defines dependencies on slf4j-api and
log4j. Now, the generated geronimo-plugin.xml has a dependency on
slf4j-log4j12 but it's missing slf4j-api and log4j dependencies. That
does not seem right or I'm missing something.
I'm working on it :-)
This is a mistake I found also. It kinda doesn't matter at the moment
because these dependencies are all in the manifest classpath entry
pointing e.g. to the slf4j-api jar in lib. If we manage to further
trim down lib and increase boot usage of the repo it will start to
matter a lot.
I'm working on converting framework/configs to use
<useTransitiveDependencies>true</useTransitiveDependencies> but its
showing up some problems with how we are computing the maven
dependency graph. I'm not sure yet if these are bugs in the maven
dependency plugin or how we're trying to use or abuse it.
thanks
david jencks
Jarek
On Thu, Aug 14, 2008 at 7:45 PM, David Jencks
<[EMAIL PROTECTED]> wrote:
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
