Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Brett Porter <brett@porterclan.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: explanation for ClassNotFoundException : RepositoryMetadataBuilder
 (and others)
Date: Tue, 1 Dec 2009 01:27:02 +1100
Message-Id: <4CA1D2F0-AC24-4AA0-90DB-BCCC5A6F6A91@porterclan.net>
To: dev@archiva.apache.org
Mime-Version: 1.0 (Apple Message framework v1077)

Hi,

We've come across this error multiple times before, and I hit it again =
this evening and wanted to document what was going on in case it became =
an issue again in the future.

It looks something like this:

jvm 1    | Caused by: java.lang.IllegalArgumentException: Cannot find =
class =
[org.apache.maven.artifact.repository.metadata.RepositoryMetadataBuilder]
jvm 1    | 	at =
org.springframework.util.ClassUtils.resolveClassName(ClassUtils.java:233)
jvm 1    | 	at =
org.springframework.beans.propertyeditors.ClassEditor.setAsText(ClassEdito=
r.java:63)
jvm 1    | 	at =
org.springframework.beans.TypeConverterDelegate.doConvertTextValue(TypeCon=
verterDelegate.java:382)
jvm 1    | 	at =
org.springframework.beans.TypeConverterDelegate.doConvertValue(TypeConvert=
erDelegate.java:358)
jvm 1    | 	at =
org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeCon=
verterDelegate.java:173)
jvm 1    | 	at =
org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeCon=
verterDelegate.java:138)
jvm 1    | 	at =
org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperIm=
pl.java:386)
jvm 1    | 	... 89 more
jvm 1    | Caused by: java.lang.ClassNotFoundException: =
org.apache.maven.artifact.repository.metadata.RepositoryMetadataBuilder
jvm 1    | 	at =
java.net.URLClassLoader$1.run(URLClassLoader.java:200)
jvm 1    | 	at java.security.AccessController.doPrivileged(Native =
Method)
jvm 1    | 	at =
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
jvm 1    |=20
jvm 1    | 	at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
jvm 1    | 	at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
jvm 1    | 	at =
org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.jav=
a:401)
jvm 1    | 	at =
org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.jav=
a:363)
jvm 1    | 	at =
org.springframework.util.ClassUtils.forName(ClassUtils.java:211)
jvm 1    | 	at =
org.springframework.util.ClassUtils.resolveClassName(ClassUtils.java:230)
jvm 1    | 	... 95 more

The reason this is occurring is because we are leaving some components =
that are declared in a bundled components.xml out of the distribution. =
Normally, they wouldn't be needed, but it seems that in certain =
circumstances Spring decides to load some classes that otherwise =
wouldn't be loaded. So far, I've only seen this occur when an error =
appears somewhere else first - perhaps in trying to resolve the error it =
keeps searching. The case above is because of differing versions of the =
Maven library dependencies. If we align those versions, other errors =
will then pop up for classes in plexus-container-default (eg =
ComponentConfigurator) which is also in some component definitions but =
not bundled.

We could make them go away by shipping the latest Maven and including =
the corresponding plexus-container-default. However, since they only =
seem to be appearing when something else goes wrong, I don't think it's =
worth making the change immediately.

Just wanted to document this for others that might see it again in the =
future :)

Cheers,
Brett=