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:
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-batik-impl</artifactId>
<version>1.0.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework</artifactId>
</exclusion>
</exclusions>
</dependency>
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:[EMAIL PROTECTED]
> Verzonden: maandag 11 december 2006 14:15
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: [2.2] cocoon-batik-impl not working?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> /Daniel
>
>
> 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
> >
> >
