Hey Sanne, This error comes from jboss-modules and its maven loader. We do try to load settings.xml and read configuration for remote repositories as well as local repositories (if user doesn’t use standard .m2/repository) There are two system properties you can pass to the server to tell him where to look To define remote repo to look at: -Dremote.maven.repo=http://path/to/repo To define local repo to load from -Dmaven.repo.local=/path/on/local/disk To tell him custom settings.xml should be used -jboss.modules.settings.xml.url=file://path/to/settings.xml Also usually it is a good practice that in testsuite you pass local repo to surefire. This works great in cases users have custom settings and you can just pass them from current maven execution settings Adding something like -Dmaven.repo.local=${settings.localRepository} To surefire args or sys props passed to Wildfly it should resolve most of issues users could face. When it comes to improving error reporting, sure that should be done. -- tomaz From: Sanne Grinovero Sent: sreda, 24. januar 2018 11:46 To: Wildfly Dev mailing list Subject: [wildfly-dev] WildFly provisioned "thin" giving confusing errors onincorrect global Maven settings TLDR: provisioning works fine, booting the server works not. Hi all, with all Hibernate ORM contributors now forced to run WildFly "provisioned in thin format" for integration tests, several people have been reporting cryptic errors such as: Failed to resolve artifact 'xerces:xercesImpl:2.11.0.SP5' (position: END_TAG seen ...resources>\n        <artifact name="xerces:xercesImpl:2.11.0.SP5"/>... @26:56) The common pattern seems to be an exception reported as "Caused by: org.jboss.modules.xml.XmlPullParserException". Turns out the problem is that they didn't have the JBoss Nexus repository activated. The provisioning tool is running with the JBoss repository being enabled - as I hardcoded this as a default - so the dependencies are actually copied into the local cache, but Maven (Aether) is keeping track of these being sourced from the JBoss Nexus, so these dependencies are unresolvable when a subsequent process is started without having the JBoss Nexus repository enabled. This could be caused by not having activated some Maven profile, or simply because the user doesn't mention the JBoss Nexus at all in his Maven global settings file, or has no global file at all. There's a number of open JIRAs and StackOverflow questions related, people are a bit lost and it seems a widespread problem [1]. I'm looking for two things: A# Could the exception be made clearer? It seems to suggest the XML is malformed, or perhaps the download corrupted, the local Maven cache needing to be nuked. B# Is there a way to boot WildFly with custom Maven configuration settings? I would want to avoid having all contributors to have to figure out they have to adjust their global Maven settings. I guess in an ideal world we'd also want to avoid needing any dependency which isn't available in Maven Central, but that seems an harder, long term goal. For the time being I'll be changing our builds to use the provisioning but avoiding the "thin" format; I'm a bit sad about that as it was very convenient, so I'm looking forward for better suggestions :) Thanks, Sanne 1 - https://stackoverflow.com/questions/41826619/wildfly-swarm-deployment-iss... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev