Chameleon should use settings.xml if provided to the parent maven task
Closed this issue · 16 comments
At the moment there is a complete new MavenWorkingSession for the chameleon runner, which ignores the settings.xml and makes trouble in corporate environments with proxy and/or mirror.
+1
This is going to keep me from being able to use this at the moment, which is a huge shame.
Thanks for reporting. Would anyone of you be interested in contributing this fix? You can count on my help any time.
Hi,
if I understand it correctly - what you are saying is that chameleon over here somehow ignores your ~/.m2/settings.xml file...?
Well, I've tried it locally and everything seem to be working without any problem... So, maybe I don't understand your problem correctly or I have completely different settings of my environment than you have.
Could you please provide more information or just a simple reproducer?
it seems to be more an issue with missing DNS resolution. But in general it would be nice if Chameleon does not encounter an issue if DNS for central.maven.org can't be resolved. I was expecting that it will ask directly at the mirror instead of resolving the DNS on its own.
What I tried - I created my dummy repository containing all necessary bits, then I disconnected my PC from the internet, set path to the dummy repo as a remote repo (in my settings.xml) and tried a build of a chameleon test - everything passed.
This is a use case which is very hard to reproduce in different environment. If you know where the problem is and you know how to fix it, we will welcome any help/hints or PR.
No, I'm saying that I run maven with mvn --settings ~/.m2/client_specific_settings.xml where I customize things specific to corporate environments (say, when I'm on a client's VPN).
Just reading settings.xml is using my normal maven settings.xml, not the one I told maven to use which has the client's corporate nexus proxies (and any other profiles required to build) defined.
On Oct 24, 2016, at 8:18 AM, Matous Jobanek notifications@github.com wrote:
What I tried - I created my dummy repository containing all necessary bits, then I disconnected my PC from the internet, set path to the dummy repo as a remote repo (in my settings.xml) and tried a build of a chameleon test - everything passed.
This is a use case which is very hard to reproduce in different environment. If you know where the problem is and you know how to fix it, we will welcome any help/hints or PR.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #53 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABk1L926SplaXjn7au0tjNMa4DhoIghxks5q3KICgaJpZM4KAqqH.
@bvarner unfortunately, this feature is not supported by ShrinkWrap Resolver (using settings.xml specified on command line). Since the SW Resolver is internally used by Chameleon, it's not possible to use it here.
You can try using SW Resolver maven plugin https://github.com/shrinkwrap/resolver#shrinkwrap-resolver-maven-plugin
Apart from using Maven plugin, there is probably no possible solution so far. If I think about it as a new feature that could be implemented, the only feasible way seems to be using arquillian.xml file and specifying it there.
Any other idea?
That's interesting, since we haven't had any other issue using shrinkwrap resolver during our integration tests that we do have running with Arquillian without chameleon... (and we're resolving artifacts that only exist in the corporate proxy defined in my alternate settings.xml)
Hrmmm...
On Oct 26, 2016, at 7:47 AM, Matous Jobanek notifications@github.com wrote:
@bvarner https://github.com/bvarner unfortunately, this feature is not supported by ShrinkWrap Resolver (using settings.xml specified on command line). Since the SW Resolver is internally used by Chameleon, it's not possible to use it here.
You can try using SW Resolver maven plugin https://github.com/shrinkwrap/resolver#shrinkwrap-resolver-maven-plugin https://github.com/shrinkwrap/resolver#shrinkwrap-resolver-maven-plugin
Apart from using Maven plugin, there is probably no possible solution so far. If I think about it as a new feature that could be implemented, the only feasible way seems to be using arquillian.xml file and specifying it there.Any other idea?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #53 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABk1L9xZwyXBtqGR1cLvDdig6XWHubgzks5q3z29gaJpZM4KAqqH.
@bvarner The only possible way I can think of (why other tests using resolver are working) is that you point to your settings.xml file using Resolver API:
Maven.configureResolver().fromFile("your/alternate/settings.xml");
or that you set the repository explicitly via the API:
Maven.configureResolver().withRemoteRepo(repository);
Looks like we're doing this (I'm not the source of this, so... I'm not sure why it was picked to do it this way)
Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies().resolve().withTransitivity().asFile()
No idea then. Maybe some additional settings in the pom.xml file. Anyway, using settings.xml file defined on command line is not supported by Resolver.
Since your use case is completely valid, I implemented a new chameleon parameter chameleonSettingsXml which should enable you to use your arbitrary settings.xml file. Please, take a look at this PR: #56
could it be that you support default shrinkwrap default system properties ?
a failsafe configuration could then look like:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<id>integration-test</id>
<phase>integration-test</phase>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
<org.apache.maven.global-settings>/d/dev/tools/apache/maven/latest/conf/settings.xml</org.apache.maven.global-settings>
</systemPropertyVariables>
</configuration>
</execution>
...
</executions>
</plugin>
the settings location file could also have been set via a property to externalize the location.
Perhaps also an already existing maven property exist for global.settings location.
If not a simple plugin could bring it int the party but here we diverge ; might be that ShrinkWrap Resolver Maven Plugin resolves exactly that.
Hi,
yeah, I didn't realized the possibility to hack it using the system properties from SWR. I have no idea why I was trying to solve it with additional properties in arq.xml, when there is already a solution implemented. I was probably too focused on the settings using -s parameter. Sorry for that.
Have you tried to use either org.apache.maven.user-settings or org.apache.maven.global-settings to solve your problem?
Have you tried to use either
org.apache.maven.user-settings...
@MatousJobanek if the question was addressed to me then I'd say no, cause sadly for the particular project I was on, I have moved away from chameleon.
@MatousJobanek I was able to spend some time coming back to chameleon today, and yes. I can confirm the system property works!
It's not as elegant as I'd like, but it's functional. Thanks!
Interesting point about snakeyaml. The dependencies of arquillian and Co loading 1.15.
The chameleon itself tries to load 1.17 via the process.
WARNUNG: Failed downloading org/yaml/snakeyaml/1.17/snakeyaml-1.17.pom from http://repo1.maven.org/maven2/. Reason:
org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.yaml:snakeyaml:pom:1.17 from/to central (http://repo1.maven.org/maven2): Error transferring file: repo1.maven.org from http://repo1.maven.org/maven2/org/yaml/snakeyaml/1.17/snakeyaml-1.17.pom
Apr 10, 2017 6:04:43 PM org.jboss.shrinkwrap.resolver.impl.maven.logging.LogTransferListener transferFailed
WARNUNG: Failed downloading org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar from http://repo1.maven.org/maven2/. Reason:
org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.yaml:snakeyaml:jar:1.17 from/to central (http://repo1.maven.org/maven2): Error transferring file: repo1.maven.org from http://repo1.maven.org/maven2/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar