Proxy exceptions are ignored

[TobiX]

I'm submitting a ...

• bug report
• feature request

What is the current behavior?

When using a proxy server with exception in the maven config, like this:

    <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy</host>
      <port>8080</port>
      <nonProxyHosts>localhost*|127.0.0.1|*.example.com|*.intern.example.com</nonProxyHosts>
    </proxy>

it is not possible to direct the allure-maven plugin to download from a host covered by the exception (For example https://artifactory.intern.example.com/), since those exceptions are not honoured.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

1. Configure some proxy in the maven settings (can be something broken, like www.google.com since it shouldn't been used
2. Add repo.maven.apache.org to the nonProxyHost list
3. Configure allure-maven to fetch the command line tool from there:

<reportVersion>2.13.7</reportVersion>
<allureDownloadUrl>https://repo.maven.apache.org/maven2/io/qameta/allure/allure-commandline/%s/allure-commandline-%s.zip</allureDownloadUrl>

4. Observe error when allure-maven tries to use the proxy, which it shouldn't

What is the expected behavior?

allure-maven shouldn't download the command line tool via proxy if the host it should download from is covered by a proxy exception. (Since current versions of the allure cli are present in Maven Central, maybe it would be best to skip downloading inside this plugin and letting Maven handle it instead)

What is the motivation / use case for changing the behavior?

Failure to run in a corperate environment with a mandatory proxy to the internet, but no proxy to the internal Artifactory installation

Please tell us about your environment:

• Allure version: 2.13.7
• Test framework: junit4@4.13.1
• Allure adaptor: allure-junit4@2.13.7
• Generate report using: allure-maven@2.10.0

Other information

[TobiX]

I consider this fixed for most common cases through #142. It's certainly fixed for my usecase. Therefore closing 😃