[wildfly-dev] WildFly provisioned "thin" giving confusing errors on incorrect global Maven settings
Sanne Grinovero
sanne at hibernate.org
Wed Jan 24 05:42:28 EST 2018
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
More information about the wildfly-dev
mailing list