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:


To define local repo to load from


To tell him custom settings.xml should be used



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



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.







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:



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 :)





1 - https://stackoverflow.com/questions/41826619/wildfly-swarm-deployment-issue-failed-to-resolve-artifact-xalanserializer2



wildfly-dev mailing list