Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 70050 invoked from network); 11 Dec 2006 15:10:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Dec 2006 15:10:25 -0000 Received: (qmail 86584 invoked by uid 500); 11 Dec 2006 15:10:31 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 86510 invoked by uid 500); 11 Dec 2006 15:10:30 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 86499 invoked by uid 99); 11 Dec 2006 15:10:30 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Dec 2006 07:10:30 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [80.89.224.70] (HELO smtp.iaf.nl) (80.89.224.70) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Dec 2006 07:10:19 -0800 Received: from server.bizzdesign.nl (bizzdesign2.cust.iaf.nl [80.89.226.18] (may be forged)) by smtp.iaf.nl (8.13.1/8.13.1) with ESMTP id kBBF5iAr014694 for ; Mon, 11 Dec 2006 16:05:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [2.2] cocoon-batik-impl not working? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 11 Dec 2006 16:06:15 +0100 Message-ID: <5E091A68F794974CAF431CA31F5AF2CC6DC6C6@server.bizzdesign.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.2] cocoon-batik-impl not working? Thread-Index: AccdJxAN3sBSFVAlQTWZ96wD/bGUNwACkrLg From: "Bart Molenkamp" To: X-IAF-MailScanner: Found to be clean X-IAF-MailScanner-From: b.molenkamp@bizzdesign.nl X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No The problem is in fop 0.20.5, which has a dependency to avalon-framework 4.0, ... batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) avalon-framework:avalon-framework:jar:4.0:compile (selected for compile) ... When including the batik block, you can exclude the dependency like you said: org.apache.cocoon cocoon-batik-impl 1.0.0-SNAPSHOT avalon-framework avalon-framework This works fine, the avalon-framework-4.0.jar is not included with the webapp or block anymore. But I'm wondering, isn't there any global setting that will exclude the jars, no matter from which dependency path they come? Or do I have to declare this for every dependency that includes avalon-framework-4.0.jar? Thanks, Bart. > -----Oorspronkelijk bericht----- > Van: Daniel Fagerstrom [mailto:danielf@nada.kth.se] > Verzonden: maandag 11 december 2006 14:15 > Aan: dev@cocoon.apache.org > Onderwerp: Re: [2.2] cocoon-batik-impl not working? >=20 > I have had the same problem. What happens is that some of the batik > libraries has a transitive dependency on some obsolete version of > avalon-framework. Normally, if there are dependencies of several > different versions of the same library, the latest of the depended > versions will be chosen by Maven. >=20 > But in this case the old version of avalon is called something like > "avalon-framework" wile the later ones are spit into an api and an > implementation part. The also have different group ids. In the end the > obsolete Avalon framework versions happens to be earlier in alphabetic > order and by consequence before in search order in the classpath. >=20 > You can test if the above is the problem by look if you have to many > Avalon framework libraries in your WEB-INF/lib, and if this is the case > remove it and restart. >=20 > To solve the situation one need to analyze how the obsolete > avalon-framework is included in the build. This can be done by building > with the -X switch. Then one can use "exclude" directives in the pom to > turn of the inclusion of the jar. >=20 > /Daniel >=20 >=20 > Bart Molenkamp skrev: > > Hi, > > > > I'm trying to experiment with Cocoon 2.2 and the batik block. But I'm > > getting an exception: > > > > 2006-12-11 13:08:03.375::WARN: Nested in > > org.springframework.beans.factory.BeanDefinitionStoreException: > > Unexpected exception parsing XML document from Se > > rvletContext resource [/WEB-INF/applicationContext.xml]; nested > > exception is java.lang.NoSuchMethodError: > > org.apache.avalon.framework.configuration.Default > > ConfigurationBuilder.build(Ljava/io/InputStream;Ljava/lang/String;)Lorg/ > > apache/avalon/framework/configuration/Configuration;: > > java.lang.NoSuchMethodError: > > org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.bu > > ild(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apach > > e/avalon/framework/configuration/Configuration; > > at > > org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadU > > RI(ConfigurationReader.java:506) > > at > > org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handl > > eInclude(ConfigurationReader.java:458) > > at > > ... > > > > I guess it is the same error like this [1]. Anybody any hint on how to > > solve this? > > > > Thanks, > > Bart. > > > > > > [1] http://www.mail-archive.com/users@cocoon.apache.org/msg36299.html > > > >