Much thanks for that! Theory is fine so far, but I am in doubt about practical usage. E.g. my DomainModel has dependency on spring-2.0.6 and EL has dependency on spring-2.5.1. So I feel like I MUST rely on 2.5.1, too, since exclusion would maybe result in errors with usage of EL, right? And if I force 2.0.6 I would be still in doubt about what happens to EL during runtime...
How can one decide wich deps are safe for exclusion (e.g. I have sample code with dep on spring-2.5.1 wich relies on asm-2.2.3. Hibernate needs asm-1.5.3 so exclusion of that would leed to errors, too, not?)? Besides: I have no parent pom for the whole project, since I don't want to rebuild myDomainBlock every time (maybe this could be achieved by using modules and build parts of them with mvn -P option). For me it is only considerable to have parent pom for all cocoon-blocks. Learning-circles always have some zero-crossings ;) Best greetings, Patrick -------- Original-Nachricht -------- > Datum: Sun, 13 Apr 2008 23:03:40 +0200 > Von: Grzegorz Kossakowski <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: pom.xml / Tomcat > Patrick Heiden pisze: > > Sorry, I've forgotten to activate logging, here an extendet version of > tomcats output, maybe now > > you are able to see what is happening: > > > > <snip/> > > > [org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl] for bean with > name > > 'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel' defined in > URL > > > [jar:file:/home/pepemuck/_opt/tomcat55/webapps/isacWebApp/WEB-INF/lib/cocoon-pipeline-impl-1.0.0-RC2.jar!/META-INF/cocoon/spring/ObjectModel.xml]: > > problem with class file or dependent class; nested exception is > java.lang.NoClassDefFoundError: > > org/apache/commons/collections/map/AbstractMapDecorator Caused by: > > java.lang.NoClassDefFoundError: > org/apache/commons/collections/map/AbstractMapDecorator > > Ok. Now everything is clear. > > Class org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl comes from > cocoon-expression-language > module, its dependencies can be found here: > http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/dependencies.html > > As you can see, EL module depends on commons-collections:3.2, now let's > take a look at your > dependencies listings: > > myDomainBlock: > [INFO] commons-collections:commons-collections:jar:2.1.1:compile > > isac: > [INFO] commons-collections:commons-collections:jar:3.2:compile > > isacWebApp: > [INFO] commons-collections:commons-collections:jar:2.1.1:compile > > As you see, wrong version (coming from myDomain) lands in your webapp and > that's why it breaks. I > think that Patrick it's crucial now for you to understand how transitive > dependencies work in Maven > in order to effectively resolve such problems. > > You sould study [1][2] and then decide to use exclusion mechanism or > direct dependency specification > (so right version is being pulled). > > [1] > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > [2] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution > > -- > Best regards, > Grzegorz Kossakowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
