Managed Wildfly 9.0.1 fails, but remote is OK with Chameleon

support
#1

I get this error when trying to use Chameleon with Wildfly 9.0.1 Managed

Caused by: org.jboss.shrinkwrap.resolver.api.NoResolvedResultException: Unable to collect/resolve dependency tree for a resolution due to: The following artifacts could not be resolved: org.jboss.invocation:jboss-invocation:jar:1.4.1.Final, org.jboss.stdio:jboss-stdio:jar:1.0.2.GA: Could not find artifact org.jboss.invocation:jboss-invocation:jar:1.4.1.Final in central (http://repo1.maven.org/maven2), caused by: Could not find artifact org.jboss.invocation:jboss-invocation:jar:1.4.1.Final in central (http://repo1.maven.org/maven2)

Any idea how to resolve this? I’m assuming that internally chameleon’s trying to download the client, but for some reasons these artifacts don’t resolve. FWIW I have my own local Artifactory setup, it would be preferable if I could tell Chameleon to go through that.

#2

Works on my machine! :smile:

As the exception says, the jboss-invocation doesn’t seem to be published in Maven Central for what ever reason.

In my setup I have the JBoss Nexus repos setup in Maven settings.xml. You could configure your own Artifactory setup in settings.xml as well and the default ShrinkWrap Resolver instance used by Chameleon should take that into account.

If you want some more direct chameleon repository configuration option of some kind, feel free to open an issue: https://github.com/arquillian/arquillian-container-chameleon/issues

#3

As far as I can tell, this is a recent change in Shrinkwrap Resolver. If you have a $MAVEN_CONF/conf/settings.xml that is ignored by the resolver. In my case that was my only settings.xml file.

Maybe we need a way to specify settings.xml in shrinkwrap.

#4

@johndament isn’t the normal location $MAVEN_CONF/settings.xml ?

#5

My response should have been MAVEN_HOME not CONF. Oops.

But even then, how would ahrinwrap know this location?

#6

If I remember correctly it will attempt to look in $USER_HOME/.m2

#7

According to the docs

ShrinkWrap Resolvers will not consume settings.xml you specified on command line (-s settings.xml) or in the IDE. It reads settings.xml files at their standard locations, which are ~/.m2/settings.xml and $M2_HOME/conf/settings.xml unless overridden in the API or via System property.

#8

Right. But what’s M2_HOME? As far as I can tell, the use of any environment variable to refer to your maven location is simply used for development purposes, even the current maven install guide makes no reference to it and instead recommends full path.

https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/task/ConfigureSettingsFromPluginTask.java#L34

I’m going to assume that this block describes the system property overrides?

#9

Hi,
M2_HOME represents path to you Maven binary: https://maven.apache.org/guides/development/guide-building-maven.html
The block you mentioned here is related to ShrinkWrap Resolver Maven plugin, so you need to have it properly configured in your pom.xml file: https://github.com/shrinkwrap/resolver#shrinkwrap-resolver-maven-plugin
If you want to use a custom settings.xml I recommend you to specify the path with the fluent API when configuring resolver:

Maven.configureResolver().fromFile("/path/to/settings.xml");
#10

Actually, I started a twitter poll to see who uses M2_HOME vs MAVEN_HOME. I may raise a PR to shrinkwrap to check both.

BTW, the link you shared https://maven.apache.org/guides/development/guide-building-maven.html is the one I referenced earlier, it’s how to build maven from source, not how to build apps from maven.

#11

In addition, don’t forget that when you’re using chameleon there’s no access to the underlying maven resolver provided to the developer.

#12

Sorry, I’m taking back my whole comment - didn’t read the whole discussion properly…

#13

Looking at your PR - yes, you right, there is no problem with checking the MAVEN_HOME variable.
Please correct me if I’m wrong - MAVEN_HOME is a variable used for Maven 1 and M2_HOME for Maven 2 and later. This is probably the reason why it wasn’t checked by default.

As far as I can tell, this is a recent change in Shrinkwrap Resolver. If
you have a $MAVEN_CONF/conf/settings.xml that is ignored by the
resolver. In my case that was my only settings.xml file.

I was trying to search in history of SWR changes if the MAVEN_HOME variable had been ever checked but didn’t find anything.

#14

I don’t believe it was ever checked previously, it’s not a regression issue. The reason it was reproducing it sometimes is that my VM image uses MAVEN_HOME, but doesn’t have ~/.m2/settings.xml, it does have $MAVEN_HOME/conf/settings.xml. I manually had it in ~/.m2 in a few cases.