jboss-metadata project has now been split up into different components (ejb, web etc...). This new version is now available in AS trunk. This has now exposed an bug within EJB3 project which maintains and ships a duplicated and incorrect xsd file, specifically the jboss_5_0.xsd. This file maps the xsd to an incorrect target namespace (targetNamespace="http://java.sun.com/xml/ns/javaee"). This issue has been exposed by the testsuite runs on Mike against AS trunk http://mike.lab.bos.redhat.com:8380/hudson/job/JBoss-AS-6.x-tests-ejb3/4/testReport/org.jboss.ejb3.test.schema.unit/DDValidationUnitTestCase/testValidation/ (needs VPN access).

The testcase relies on the jboss_5_0.xsd being picked up from the classpath during validation. It was just by chance, that earlier, the xsd was being picked up from the jboss-metadata.jar which contains the correct version of this xsd:

2009-11-22 20:01:53,374 TRACE [org.jboss.util.xml.JBossEntityResolver] schema/jboss_5_0.xsd maps to URL: jar:file:/home/me/jboss-5.1.0.GA/client/jboss-metadata.jar!/schema/jboss_5_0.xsd

However, when running this against AS trunk, the xsd now gets picked up from the jboss-ejb3-core, which contains the incorrect xsd:

2009-11-22 20:00:54,603 TRACE [org.jboss.util.xml.JBossEntityResolver] schema/jboss_5_0.xsd maps to URL: jar:file:/home/me/ejb3/trunk/testsuite/target/dependencies/lib/jboss-ejb3-core.jar!/schema/jboss_5_0.xsd

This is a more generic issue, since looking at the ejb3-core component, it seems to ship the following xsds too:

application_5.xsd
ejb-jar_3_0.xsd
javaee_web_services_1_2.xsd
jboss_5_0.dtd
sun-ejb-jar_3_0.xsd
application-client_5.xsd
javaee_5.xsd
javaee_web_services_client_1_2.xsd
jboss_5_0.xsd

Ideally, these should be shipped by the project which maintains these metadata. And now that the metadata project has been split up per component, it makes more sense to let the individual metadata components ship the correct versions of these xsds. For example, the EJB3 specific xsds should come from the jboss-metadata-ejb project.