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-issue-failed-to-resolve-artifact-xalanserializer2
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev