[jira] [Updated] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files

[*$^¨%`£]

 [ 
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) updated MSHADE-291:
--
Affects Version/s: 3.2.0
   3.2.1

> shadedPattern applied multiples times when relocating the contents of 
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.1, 3.2.0, 3.2.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.2.2
>
>
> Steps to reproduce:
> 1. Modified the test case for 
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>  
>  org.apache.maven.plugins
>  maven-shade-plugin
> -2.4
> +3.1.1
>  
>  
>  
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>  
>  
>  
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows: 
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files

[*$^¨%`£]

 [ 
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) updated MSHADE-291:
--
Fix Version/s: (was: 3.2.1)
   3.2.2

> shadedPattern applied multiples times when relocating the contents of 
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.2.2
>
>
> Steps to reproduce:
> 1. Modified the test case for 
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>  
>  org.apache.maven.plugins
>  maven-shade-plugin
> -2.4
> +3.1.1
>  
>  
>  
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>  
>  
>  
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows: 
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683171#comment-16683171
 ] 

Hudson commented on MSHADE-291:
---

Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » master #55

See 
https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/55/

> shadedPattern applied multiples times when relocating the contents of 
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.2.1
>
>
> Steps to reproduce:
> 1. Modified the test case for 
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>  
>  org.apache.maven.plugins
>  maven-shade-plugin
> -2.4
> +3.1.1
>  
>  
>  
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>  
>  
>  
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows: 
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1598) Fixed typo in assertion statement in integration test Surefire855AllowFailsafeUseArtifactFileIT

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1598:
--

 Summary: Fixed typo in assertion statement in integration test 
Surefire855AllowFailsafeUseArtifactFileIT
 Key: SUREFIRE-1598
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1598
 Project: Maven Surefire
  Issue Type: Test
Affects Versions: 3.0.0-M1
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M2






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1596) Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests

[Tibor Digana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1596:
---
Issue Type: Test  (was: Improvement)

> Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests
> ---
>
> Key: SUREFIRE-1596
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1596
> Project: Maven Surefire
>  Issue Type: Test
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Not needed in unit tests, e.g.:
> {code:java}
> @BeforeClass
> public static void withJava7Plus()
> {
> assumeTrue( JAVA_RECENT.atLeast( JAVA_1_7 ) );
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1597) ModularClasspathForkConfiguration with debug logs (@args file and its path on file system)

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1597:
--

 Summary: ModularClasspathForkConfiguration with debug logs (@args 
file and its path on file system)
 Key: SUREFIRE-1597
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1597
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M2


Added debug logs (@args file and its path on file system).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1596) Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1596:
--

 Summary: Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests
 Key: SUREFIRE-1596
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1596
 Project: Maven Surefire
  Issue Type: Improvement
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M2


Not needed in unit tests, e.g.:


{code:java}
@BeforeClass
public static void withJava7Plus()
{
assumeTrue( JAVA_RECENT.atLeast( JAVA_1_7 ) );
}
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1595) Java 1.7 feature System.lineSeparator()

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1595:
--

 Summary: Java 1.7 feature System.lineSeparator()
 Key: SUREFIRE-1595
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1595
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M2


Used in a place of {{System.getProperty( "line.separator" )}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1594) Java 1.7 feature try-catch - multiple exceptions in one catch

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1594:
--

 Summary: Java 1.7 feature try-catch - multiple exceptions in one 
catch
 Key: SUREFIRE-1594
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1594
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M2


The last occurrence was not changed to Java 1.7 style in 
{{SurefireDependencyResolver}} after the version {{3.0.0-M1}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSITE-828) Jdk 1.8 required / Upgrade Jetty Version 9.4.12

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683025#comment-16683025
 ] 

ASF GitHub Bot commented on MSITE-828:
--

michael-o commented on issue #3: [MSITE-828] Upgrade jetty to recent version. 
Update to java 1.8 (required for jetty)
URL: https://github.com/apache/maven-site-plugin/pull/3#issuecomment-437709471
 
 
   I see the point, though 9.2 is updated regularily: 9.2.26.v20180806. I don't 
mind updating per se, but I don't understand how it will improve security if 
this is testing only and not a compile/runtime dependency. In other words, it 
is never pulled by a third party.
   
   Anyway, I don't see it fixed with 
https://github.com/eclipse/jetty.project/commits/jetty-9.2.x.
   
   It seems fine to me to make this bump for 3.8. BUT I'd like to see "Upgrade 
to Java 8" with a seperate ticket and a subsequent one with Jetty. It makes the 
stuff transparent for our users.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Jdk 1.8 required / Upgrade Jetty Version 9.4.12
> ---
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SUREFIRE-1591) Java 1.7 feature Diamonds replaced Generics

[Tibor Digana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1591:
--

Assignee: Tibor Digana

> Java 1.7 feature Diamonds replaced Generics
> ---
>
> Key: SUREFIRE-1591
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1591
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Java 1.7 does not require specifying Generics in constructor for  variable 
> assignment.
> {code:java}
> Map> mergedTestHistoryResult = new 
> HashMap>();
> {code}
> turns to in Java 1.7:
> {code:java}
> Map> mergedTestHistoryResult = new HashMap<>();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1591) Java 1.7 feature Diamonds replaced Generics

[Tibor Digana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1591:
---
Summary: Java 1.7 feature Diamonds replaced Generics  (was: Java 1.7 does 
not require specifying Generics in constructor for  variable assignment)

> Java 1.7 feature Diamonds replaced Generics
> ---
>
> Key: SUREFIRE-1591
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1591
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> {code:java}
> Map> mergedTestHistoryResult = new 
> HashMap>();
> {code}
> turns to in Java 1.7:
> {code:java}
> Map> mergedTestHistoryResult = new HashMap<>();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1591) Java 1.7 feature Diamonds replaced Generics

[Tibor Digana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1591:
---
Description: 
Java 1.7 does not require specifying Generics in constructor for  variable 
assignment.

{code:java}
Map> mergedTestHistoryResult = new 
HashMap>();
{code}

turns to in Java 1.7:

{code:java}
Map> mergedTestHistoryResult = new HashMap<>();
{code}




  was:

{code:java}
Map> mergedTestHistoryResult = new 
HashMap>();
{code}

turns to in Java 1.7:

{code:java}
Map> mergedTestHistoryResult = new HashMap<>();
{code}





> Java 1.7 feature Diamonds replaced Generics
> ---
>
> Key: SUREFIRE-1591
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1591
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Java 1.7 does not require specifying Generics in constructor for  variable 
> assignment.
> {code:java}
> Map> mergedTestHistoryResult = new 
> HashMap>();
> {code}
> turns to in Java 1.7:
> {code:java}
> Map> mergedTestHistoryResult = new HashMap<>();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSITE-828) Jdk 1.8 required / Upgrade Jetty Version 9.4.12

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683017#comment-16683017
 ] 

ASF GitHub Bot commented on MSITE-828:
--

oflebbe commented on issue #3: [MSITE-828] Upgrade jetty to recent version. 
Update to java 1.8 (required for jetty)
URL: https://github.com/apache/maven-site-plugin/pull/3#issuecomment-437706811
 
 
   Hi Michael,
   
   latest jetty 9.2.26 has at least four known vulnerabilities: CVE-2017-7656, 
CVE-2017-7658, CVE-2017-7657, CVE-2017-9735
   
   Some seem pretty serious to me. There seems to be a reason why it is not 
maintained any more.
   
   Do you want to argue that an Apache project can deliver insecure software 
since it is only used for "testing" ?
   
   Please keep in mind that the versions chosen will be picked up by 3rd party 
project through transitive dependencies.
   
   Best Regards,
   Olaf
   
   
   
   > Am 10.11.2018 um 13:17 schrieb Michael Osipov :
   > 
   > @olamy  @oflebbe  I 
definitvely see your point, but Jetty 9.2 does its job for testing. As for 
bumping a Java version: I see this as valid as soon as someone provides good 
code using those features. When I see how slow we are changing stuff, I don't 
see this happening beyond 2019. Just for the sake of upgrading, I wouldn't do 
this.
   > 
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub 
, or 
mute the thread 
.
   > 
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Jdk 1.8 required / Upgrade Jetty Version 9.4.12
> ---
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683002#comment-16683002
 ] 

Michael Osipov edited comment on WAGON-538 at 11/11/18 8:42 PM:


That's weird it is still present in 4.5.x in 
{{RFC2617Scheme#getCredentialsCharset(HttpRequest)}}. Did you enable logging 
and check for the base 64 value?
The SO answer is from The Oleg. I am a core committer of HttpClient too, but 
very low activity.

Can you try to set a break point in your IDE on that spot? It should actually 
have been set, if not this may be a bug in Wagon.

We officially support Basic, Digest and NTLM. The SPNEGO module is broken, see 
my ticket in HTTPCLIENT. I might consider only those three explicitly and make 
the param configurable.


was (Author: michael-o):
That's weird it is still present in 4.5.x in 
{{RFC2617Scheme#getCredentialsCharset(HttpRequest)}}. Did you enable logging 
and check for the base 64 value?
The SO answer is from The Oleg. I am a core committer of HttpClient too, but 
very low activity.

Can you try to set a break point in your IDE on that spot? It should actually 
have been set, if not this may be a bug in Wagon.

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683002#comment-16683002
 ] 

Michael Osipov edited comment on WAGON-538 at 11/11/18 8:41 PM:


That's weird it is still present in 4.5.x in 
{{RFC2617Scheme#getCredentialsCharset(HttpRequest)}}. Did you enable logging 
and check for the base 64 value?
The SO answer is from The Oleg. I am a core committer of HttpClient too, but 
very low activity.

Can you try to set a break point in your IDE on that spot? It should actually 
have been set, if not this may be a bug in Wagon.


was (Author: michael-o):
That's weird it is still present in 4.5.x in 
{{RFC2617Scheme#getCredentialsCharset(HttpRequest)}}. Did you enable logging 
and check for the base 64 value?
The SO answer is from The Oleg. I am a core committer of HttpClient too, but 
very low activity.

Can you try to set a break point in your IDE on that spot. It should actually 
have been set, if not this may be a bug in Wagon.

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683002#comment-16683002
 ] 

Michael Osipov commented on WAGON-538:
--

That's weird it is still present in 4.5.x in 
{{RFC2617Scheme#getCredentialsCharset(HttpRequest)}}. Did you enable logging 
and check for the base 64 value?
The SO answer is from The Oleg. I am a core committer of HttpClient too, but 
very low activity.

Can you try to set a break point in your IDE on that spot. It should actually 
have been set, if not this may be a bug in Wagon.

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-714) When artifact not found on mirror the real site isn't checked

[Igor Dvorzhak (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683001#comment-16683001
 ] 

Igor Dvorzhak commented on MNG-714:
---

Why this issue is closed? Was something done to address failover to mirrored 
repository if mirror not accessible or artifact is not present in mirror.

Looks like this is a must have feature taking into account that "mirroring the 
entire central repository is not allowed":
https://maven.apache.org/guides/mini/guide-mirror-settings.html

> When artifact not found on mirror the real site isn't checked
> -
>
> Key: MNG-714
> URL: https://issues.apache.org/jira/browse/MNG-714
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0-beta-1
>Reporter: Kenney Westerhof
>Assignee: Jason van Zyl
>Priority: Major
> Attachments: MNG-714-maven-artifact-manager.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> I'm using the settings.xml mirror feature as a local cache. Periodically I 
> upload my local repo
> to the webserver specified as mirror.
> When an artifact cannot be found on the mirror, the original site isn't 
> checked (and possibly the rest of the sites).
> I'm not sure what the exact function of the mirror is (except caching?), but 
> repo1 is checked often regardless
> of mirror presence, so I figure it's not meant to totally disable checking 
> the central repo's.
> Simple reproduction: define a few mirrors in your settings.xml for central, 
> central-plugins and snapshots, pointing to
> say file://tmp/empty/dir/.
> Stacktrace:
> [DEBUG] Error resolving artifact version from metadata.
> org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate 
> resource in repository
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81)
> at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70)
> at 
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343)
> at 
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263)
> at 
> org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93)
> at 
> org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171)
> at 
> org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96)
> at 
> org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274)
> at 
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156)
> at 
> org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544)
> at 
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229)
> 

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682995#comment-16682995
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501824
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   @sormuras 
   A motivation can be e.g. `AbstractSurefireMojoTest` or 
`AbstractSurefireMojoJava7PlusTest`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501824
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   @sormuras 
   A motivation can be e.g. `AbstractSurefireMojoTest` or 
`AbstractSurefireMojoJava7PlusTest`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682988#comment-16682988
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501377
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   We are having low coverage without unit tests which is bad reputation for a 
test f/w. The green curve goes down but the red one is worse because uncovered 
lines grow with this commit since the lack of unit tests. The tests will be a 
good platform for making fast experiments rather than executing all the build 
and debugging a plugin. Unit testing must be a fun for a developer because he 
can see that it works - it's green again.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via 

[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501377
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   We are having low coverage without unit tests which is bad reputation for a 
test f/w. The green curve goes down but the red one is worse because uncovered 
lines grow with this commit since the lack of unit tests. The tests will be a 
good platform for making fast experiments rather than executing all the build 
and debugging a plugin. Unit testing must be a fun for a developer because he 
can see that it works - it's green again.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682984#comment-16682984
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501049
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   It's not really our Maven style. Try to experiment with these calls:
   `Artifact.getAvailableVersions()` and `ArtifactVersion.getMajorVersion()`, 
minor, incremental, classifier, etc. It's definitely better than 
`getBaseVersion().substring( 1 )`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232501049
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   It's not really our Maven style. Try to experiment with these calls:
   `Artifact.getAvailableVersions()` and `ArtifactVersion.getMajorVersion()`, 
minor, incremental, classifier, etc. It's definitely better than 
`getBaseVersion().substring( 1 )`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (MNG-6505) child.(x.y).inherit.append.path value should be inherited

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MNG-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MNG-6505.
--
Resolution: Fixed

done in 
https://gitbox.apache.org/repos/asf?p=maven.git=commit=f97316ceeca8d7e79c81f16e2de7447e81471304
 and 
https://gitbox.apache.org/repos/asf?p=maven.git=commit=07bd5507ae88006b95565244d421aef652afd74e

> child.(x.y).inherit.append.path value should be inherited
> -
>
> Key: MNG-6505
> URL: https://issues.apache.org/jira/browse/MNG-6505
> Project: Maven
>  Issue Type: Bug
>  Components: Inheritance and Interpolation
>Affects Versions: 3.6.0
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Critical
> Fix For: 3.6.1
>
>
> in Maven 3.6.0, values of child.inherit.append.path are not inherited: they 
> have to be explicitely defined in every child pom of they switch to default 
> "true" value
> these values should be inherited: once defined in a parent pom, every child 
> should inherit from the value (and of course be able to override)
> Note: this seems to have been part of the MNG-6059 implementation that was 
> done for Maven dropped 3.4.0 version but was forgotten during Maven 3.6.0 
> merge...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MNG-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MNG-6059.
--
Resolution: Fixed

done in 
https://gitbox.apache.org/repos/asf?p=maven.git=commit=db462ae0b3d36928c6a5938469a223c0d3c4ab50

> Important use cases not covered, as child.inherit.append.path affects all 
> children
> --
>
> Key: MNG-6059
> URL: https://issues.apache.org/jira/browse/MNG-6059
> Project: Maven
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation
>Affects Versions: 3.6.0
> Environment: Apache Maven 3.4.0-SNAPSHOT 
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
>Reporter: Andreas Sewe
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.1
>
>
> The {{child.inherit.append.path}} attribute introduced with MNG-5951 
> unfortunately does not support the use case where the children of the element 
> with the attribute should follow different inheritance rules. Take a typical 
> configuration for Github, for example (taken from 
> <[http://central.sonatype.org/pages/requirements.html]>):
> {noformat}
> 
>   
> scm:git:git://github.com/simpligility/ossrh-demo.git
>   
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
>   http://github.com/simpligility/ossrh-demo/tree/master
> 
> {noformat}
> If the {{ossrh-demo.git}} repository contains a child module called 
> {{some-module}}, then that child’s {{scm/url}} should become 
> {{[http://github.com/simpligility/ossrh-demo/tree/master/some-module]}} as 
> per the normal inheritance rules, but both the {{scm/connection}} and 
> {{scm/developerConnection}} URLs should remain unchanged.
> Unfortunately, this is not possible with {{*child*.inherit.append.path}}, 
> which acts on all children simultaneously.
> IMHO, this is a conceptual problem. In particular, setting 
> {{child.inherit.append.path}} on the *root* element to just control a single 
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood 
> not even located close to the {{}} element it controls.
> h1. Implemented Solution
> {code:xml}
>   ...
>   child.scm.developerConnection.inherit.append.path="false"
>child.scm.url.inherit.append.path="false">
> ...
> ...
> ...
>   
>   
> 
>   ...
> 
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Aleksander Gjermundsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682974#comment-16682974
 ] 

Aleksander Gjermundsen commented on WAGON-538:
--

I had not considered your comment in WAGON-487. That would accomplish what I 
need to do, if I could get it to work.

I tried the following in settings.xml, but it did not make a difference to the 
header that was sent:
{code}

nexus
userØ
userØ





http.auth.credential-charset
UTF-8






{code}

Looking at the documentation for HttpClient, I can see that property mentioned 
here for version 4.2:
https://hc.apache.org/httpcomponents-client-4.2.x/tutorial/html/authentication.html
But then for version 4.5 that Wagon uses it is no longer mentioned (or any 
other properties for that matter):
https://hc.apache.org/httpcomponents-client-4.5.x/tutorial/html/authentication.html

I based my fix on this Stackoverflow post:
https://stackoverflow.com/questions/27955067/use-of-non-ascii-credentials-not-working-in-httpclient-4-3-x
It suggests that the encoding scheme no longer can be configured globally? Not 
sure if this is the Oleg that is one of the core commiters on HttpClient.


> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682971#comment-16682971
 ] 

Hudson commented on MNG-6509:
-

Build succeeded in Jenkins: Maven TLP » maven » master #110

See https://builds.apache.org/job/maven-box/job/maven/job/master/110/

> Upgrade maven-dependency-plugin to 3.1.1
> 
>
> Key: MNG-6509
> URL: https://issues.apache.org/jira/browse/MNG-6509
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: Integration Tests
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
>
> Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal 
> in Bootstrap ITs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682972#comment-16682972
 ] 

Hudson commented on MNG-6481:
-

Build succeeded in Jenkins: Maven TLP » maven » master #110

See https://builds.apache.org/job/maven-box/job/maven/job/master/110/

> Allow to compile and test Maven with Java 11
> 
>
> Key: MNG-6481
> URL: https://issues.apache.org/jira/browse/MNG-6481
> Project: Maven
>  Issue Type: Improvement
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> Java 11 is coming closer, let's prepare to use it for the development of 
> Maven.
> A minimal requirement to run Maven - still Java 7.
>  * compile and pass Maven's tests with Java 11
>  * adjust ITs to run under Java 11
> Do we need compile and to pass all tests with Java 9, 10 and 11?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6505) child.(x.y).inherit.append.path value should be inherited

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682970#comment-16682970
 ] 

Hudson commented on MNG-6505:
-

Build succeeded in Jenkins: Maven TLP » maven » master #110

See https://builds.apache.org/job/maven-box/job/maven/job/master/110/

> child.(x.y).inherit.append.path value should be inherited
> -
>
> Key: MNG-6505
> URL: https://issues.apache.org/jira/browse/MNG-6505
> Project: Maven
>  Issue Type: Bug
>  Components: Inheritance and Interpolation
>Affects Versions: 3.6.0
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Critical
> Fix For: 3.6.1
>
>
> in Maven 3.6.0, values of child.inherit.append.path are not inherited: they 
> have to be explicitely defined in every child pom of they switch to default 
> "true" value
> these values should be inherited: once defined in a parent pom, every child 
> should inherit from the value (and of course be able to override)
> Note: this seems to have been part of the MNG-6059 implementation that was 
> done for Maven dropped 3.4.0 version but was forgotten during Maven 3.6.0 
> merge...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682969#comment-16682969
 ] 

Hudson commented on MNG-6059:
-

Build succeeded in Jenkins: Maven TLP » maven » master #110

See https://builds.apache.org/job/maven-box/job/maven/job/master/110/

> Important use cases not covered, as child.inherit.append.path affects all 
> children
> --
>
> Key: MNG-6059
> URL: https://issues.apache.org/jira/browse/MNG-6059
> Project: Maven
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation
>Affects Versions: 3.6.0
> Environment: Apache Maven 3.4.0-SNAPSHOT 
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
>Reporter: Andreas Sewe
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.1
>
>
> The {{child.inherit.append.path}} attribute introduced with MNG-5951 
> unfortunately does not support the use case where the children of the element 
> with the attribute should follow different inheritance rules. Take a typical 
> configuration for Github, for example (taken from 
> <[http://central.sonatype.org/pages/requirements.html]>):
> {noformat}
> 
>   
> scm:git:git://github.com/simpligility/ossrh-demo.git
>   
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
>   http://github.com/simpligility/ossrh-demo/tree/master
> 
> {noformat}
> If the {{ossrh-demo.git}} repository contains a child module called 
> {{some-module}}, then that child’s {{scm/url}} should become 
> {{[http://github.com/simpligility/ossrh-demo/tree/master/some-module]}} as 
> per the normal inheritance rules, but both the {{scm/connection}} and 
> {{scm/developerConnection}} URLs should remain unchanged.
> Unfortunately, this is not possible with {{*child*.inherit.append.path}}, 
> which acts on all children simultaneously.
> IMHO, this is a conceptual problem. In particular, setting 
> {{child.inherit.append.path}} on the *root* element to just control a single 
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood 
> not even located close to the {{}} element it controls.
> h1. Implemented Solution
> {code:xml}
>   ...
>   child.scm.developerConnection.inherit.append.path="false"
>child.scm.url.inherit.append.path="false">
> ...
> ...
> ...
>   
>   
> 
>   ...
> 
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682965#comment-16682965
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232499728
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   > Who can say that the versions will be always like this?
   
   The @junit-team -- I guess, it'll stay like this "heuristic" for the next 
5-10 years.
   
   > Somebody has to watch the versions in Maven Central and still update this 
code.
   
   Sure. Unless we introduce a metadata engine artifact hint, like described 
here: https://github.com/junit-team/junit5/issues/1669
   
   > What if the version is not successfully resolved?
   
   The execution of Surefire fails for the project. Users may always provide 
the correct `junit-vintage-engine` in their project pom dependencies and 
prevent this code path to be executed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically 

[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232499728
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   > Who can say that the versions will be always like this?
   
   The @junit-team -- I guess, it'll stay like this "heuristic" for the next 
5-10 years.
   
   > Somebody has to watch the versions in Maven Central and still update this 
code.
   
   Sure. Unless we introduce a metadata engine artifact hint, like described 
here: https://github.com/junit-team/junit5/issues/1669
   
   > What if the version is not successfully resolved?
   
   The execution of Surefire fails for the project. Users may always provide 
the correct `junit-vintage-engine` in their project pom dependencies and 
prevent this code path to be executed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682934#comment-16682934
 ] 

ASF GitHub Bot commented on MCOMPILER-306:
--

Stephan202 opened a new pull request #9: [MCOMPILER-306] Fix `compilerArgs` 
example usage
URL: https://github.com/apache/maven-compiler-plugin/pull/9
 
 
   This is a resubmission of PR apache/maven-plugins#126.
   
   I hereby declare this contribution to be licenced under the [Apache License 
Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0).


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Priority: Major
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Stephan202 opened a new pull request #9: [MCOMPILER-306] Fix `compilerArgs` example usage

[GitBox]

Stephan202 opened a new pull request #9: [MCOMPILER-306] Fix `compilerArgs` 
example usage
URL: https://github.com/apache/maven-compiler-plugin/pull/9
 
 
   This is a resubmission of PR apache/maven-plugins#126.
   
   I hereby declare this contribution to be licenced under the [Apache License 
Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0).


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Comment Edited] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682925#comment-16682925
 ] 

Michael Osipov edited comment on WAGON-538 at 11/11/18 4:26 PM:


I have considered the same patch for the linked issue, but discarded it for two 
reasons:

1. It explicitly sets the auth providers, users cannot control it
2. We enforce the encoding though we don't know this is correct or not

More over, something like this has actually to be on a per-server basis, but 
Wagon's design does not allow that. A Maven-wide config is just a bad 
compromise.


was (Author: michael-o):
I have considered the same patch for the linked issue, but discarded it for two 
reasons:

1. It explicitly sets the auth providers, users cannot control it
2. We enforce the encoding though we don't know this is correct or not

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-6511) Option -pl ! foo should not fail if foo does not exist

[Falko Modler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682926#comment-16682926
 ] 

Falko Modler edited comment on MNG-6511 at 11/11/18 4:28 PM:
-

Ok, sounds good!

While not directly related to the scope of this ticket, what do you think about 
wildcards like:
- {{\*\-somesuffix}}
- {{?\*\-somesuffix}}
- {{someprefix-\*}}
- {{?someprefix-\*}}

etc.?
I actually did have the need for such wildcards more often than not.


was (Author: famod):
Ok, sounds good!

While not directly related to the scope of this ticket, what do you think about 
wildcards like {{*-somesuffix}}, {{?*-somesuffix}}, {{someprefix-*}}, 
{{?someprefix-*}} etc.?
I actually did have the need for such wildcards more often than not.

> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when 
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really 
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options 
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_, 
> etc.) on different hierarchy levels of larger multi module project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist

[Falko Modler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682926#comment-16682926
 ] 

Falko Modler commented on MNG-6511:
---

Ok, sounds good!

While not directly related to the scope of this ticket, what do you think about 
wildcards like {{*-somesuffix}}, {{?*-somesuffix}}, {{someprefix-*}}, 
{{?someprefix-*}} etc.?
I actually did have the need for such wildcards more often than not.

> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when 
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really 
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options 
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_, 
> etc.) on different hierarchy levels of larger multi module project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682925#comment-16682925
 ] 

Michael Osipov commented on WAGON-538:
--

I have considered the same patch for the linked issue, but discarded it for two 
reasons:

1. It explicitly sets the auth providers, users cannot control it
2. We enforce the encoding though we don't know this is correct or not

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682924#comment-16682924
 ] 

Michael Osipov commented on WAGON-538:
--

Have you considered: 
https://issues.apache.org/jira/browse/WAGON-487?focusedCommentId=16427470=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16427470?

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Moved] (WAGON-538) Basic authentication fails if the password contains non-ascii characters

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov moved MNG-6514 to WAGON-538:
---

Key: WAGON-538  (was: MNG-6514)
Project: Maven Wagon  (was: Maven)

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6514) Basic authentication fails if the password contains non-ascii characters

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682911#comment-16682911
 ] 

ASF GitHub Bot commented on MNG-6514:
-

aleksgj opened a new pull request #52: [MNG-6514] Adding support for encoding 
basic auth credentials with UT…
URL: https://github.com/apache/maven-wagon/pull/52
 
 
   MNG-6514 Saved password with umlaut breaks deployment


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: MNG-6514
> URL: https://issues.apache.org/jira/browse/MNG-6514
> Project: Maven
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6514) Basic authentication fails if the password contains non-ascii characters

[Aleksander Gjermundsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682912#comment-16682912
 ] 

Aleksander Gjermundsen commented on MNG-6514:
-

https://github.com/apache/maven-wagon/pull/52

> Basic authentication fails if the password contains non-ascii characters
> 
>
> Key: MNG-6514
> URL: https://issues.apache.org/jira/browse/MNG-6514
> Project: Maven
>  Issue Type: Bug
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains 
> non-ascii characters, the authentication fails with an access denied error. 
> After using Wireshark to investigate the headers being sent (in my case "Ø", 
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
> 
> 
> artifactory
> userØ
> userØ
> 
> 
> ...
> 
> 
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
> 
> 
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
> reads the username and passwords correctly into strings, but Apache 
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where 
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it 
> is not completely clear from the standards how these characters are supposed 
> to be handled, but on my system both wget and the Chrome web browser encode 
> the characters the same way as after my patch and are able to download files 
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in 
> contrast to Maven it was not able to decode the username and password 
> correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] aleksgj opened a new pull request #52: [MNG-6514] Adding support for encoding basic auth credentials with UT…

[GitBox]

aleksgj opened a new pull request #52: [MNG-6514] Adding support for encoding 
basic auth credentials with UT…
URL: https://github.com/apache/maven-wagon/pull/52
 
 
   MNG-6514 Saved password with umlaut breaks deployment


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (MNG-6514) Basic authentication fails if the password contains non-ascii characters

[Aleksander Gjermundsen (JIRA)]

Aleksander Gjermundsen created MNG-6514:
---

 Summary: Basic authentication fails if the password contains 
non-ascii characters
 Key: MNG-6514
 URL: https://issues.apache.org/jira/browse/MNG-6514
 Project: Maven
  Issue Type: Bug
Reporter: Aleksander Gjermundsen


If the username and/or password used to authenticate to Nexus contains 
non-ascii characters, the authentication fails with an access denied error. 
After using Wireshark to investigate the headers being sent (in my case "Ø", 
any non-ascii characters are replaced with "?".

To test, I have used the following configuration:
{code:java}
http://maven.apache.org/SETTINGS/1.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
...


artifactory
userØ
userØ


...


nexus
*
Local Nexus
http://localhost:8081/repository/maven-public


...
{code}

The settings.xml file is saved using UTF-8 encoding and it appears that Maven 
reads the username and passwords correctly into strings, but Apache HttpClient 
do not encode the UTF-8 characters when encoding them into base64.

I did a quick patch of Wagon to make it work for my use case, where HttpClient 
is configured to encode as UTF-8. As is mentioned in MNG-5917, it is not 
completely clear from the standards how these characters are supposed to be 
handled, but on my system both wget and the Chrome web browser encode the 
characters the same way as after my patch and are able to download files from 
Nexus.

Since Artifactory was used in MNG-5917, I also tested against that, but in 
contrast to Maven it was not able to decode the username and password 
correctly, however it would be broken without the patch anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6511) Option -pl ! foo should not fail if foo does not exist

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MNG-6511:

Component/s: Command Line

> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when 
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really 
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options 
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_, 
> etc.) on different hierarchy levels of larger multi module project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte reassigned MNG-6261:
---

Assignee: (was: Robert Scholte)

> Relative parent POM resolution failing in 3.5.0 with complex multimodule 
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
>  Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java 
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when 
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for 
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find 
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex 
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy 
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I 
> wonder if it's a regression bug or maybe underspecified Maven requirement 
> (that should be enforced with a warning and not lead to this odd runtime 
> message).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MJDEPS-16) Include project dependencies in scan

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MJDEPS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte reassigned MJDEPS-16:


Assignee: (was: Robert Scholte)

> Include project dependencies in scan
> 
>
> Key: MJDEPS-16
> URL: https://issues.apache.org/jira/browse/MJDEPS-16
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.5.3 
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /Users/aalmiray/.sdkman/candidates/maven/current
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_CH, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.5", arch: "x86_64", family: "mac"
>Reporter: Andres Almiray
>Priority: Major
>  Labels: up-for-grabs
>
>  
> Version 3.1.1 executes jdeps on production (goal: jdkinternals) and test 
> (goal: test-jdkinternals) sources but does not consider dependencies. This 
> means the report will tell you if product sources are complaint or not but 
> does not tell you if the packaged/deployed project would encounter problems 
> or not.
> At the very least Compile/Runtime dependencies should be scanned. Please make 
> this the default behavior. Perhaps it would be good to have a flag to skip 
> this behavior if anyone would like to have the previous behavior.
> For reference, this issue was discussed with Robert Scholte during JCrete 
> 2018.
> *Minimum POM example:*
> {code:java}
> http://maven.apache.org/POM/4.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd;>
>     4.0.0
>     com.acme
>     sample
>     jar
>     0.0.0-SNAPSHOT
>     
>     
>     
>     org.apache.maven.plugins
>     maven-jdeps-plugin
>     3.1.1
>     
>   
>     
>   jdkinternals
>     
>   
>     
>     
>     
>     
>     
>     
>     com.google.inject
>     guice
>     4.2.0
>         
> 
>     com.google.guava
>     guava
>     25.1-jre
>     
>     
>    
> {code}
> Output
> {code:java}
> $ mvn jdeps:jdkinternals
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< com.acme:sample 
> >---
> [INFO] Building sample 0.0.0-SNAPSHOT
> [INFO] [ jar 
> ]-
> [INFO]
> [INFO] --- maven-jdeps-plugin:3.1.1:jdkinternals (default-cli) @ sample ---
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.506 s
> [INFO] Finished at: 2018-07-27T09:50:39+02:00
> [INFO] 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MSHADE-291.
-
   Resolution: Fixed
 Assignee: Robert Scholte
Fix Version/s: 3.2.1

Fix in 
[52eed09e80190900b866f620544555087f27df58|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commit;h=52eed09e80190900b866f620544555087f27df58]
thanks for the patch!

> shadedPattern applied multiples times when relocating the contents of 
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.2.1
>
>
> Steps to reproduce:
> 1. Modified the test case for 
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>  
>  org.apache.maven.plugins
>  maven-shade-plugin
> -2.4
> +3.1.1
>  
>  
>  
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>  
>  
>  
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows: 
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682822#comment-16682822
 ] 

ASF GitHub Bot commented on MSHADE-291:
---

rfscholte closed pull request #9: [MSHADE-291] - Fixes bug in 
ServicesResourceTransformer
URL: https://github.com/apache/maven-shade-plugin/pull/9
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/pom.xml b/pom.xml
index 8fca8d3..cb10a84 100644
--- a/pom.xml
+++ b/pom.xml
@@ -78,6 +78,9 @@
 
   Anthony Dahanne
 
+
+  Fabiano Cipriano de Oliveira
+
   
 
   
diff --git 
a/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
 
b/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
index f1cb9d6..d087522 100644
--- 
a/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
+++ 
b/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
@@ -138,20 +138,6 @@ public void modifyOutputStream( JarOutputStream jos )
 
 while ( ( className = reader.readLine() ) != null )
 {
-
-if ( relocators != null )
-{
-for ( Relocator relocator : relocators )
-{
-//if the class can be relocated then relocate it
-if ( relocator.canRelocateClass( className ) )
-{
-className = relocator.applyToSourceContent( 
className );
-break;
-}
-}
-}
-
 writer.println( className );
 writer.flush();
 }
diff --git 
a/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
 
b/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
index a9f78db..18dab2f 100644
--- 
a/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
+++ 
b/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
@@ -89,6 +89,50 @@ public void relocatedClasses() throws Exception {
 tempJar.delete();
 }
 }
+
+@Test
+public void concatanationAppliedMultipleTimes() throws Exception {
+SimpleRelocator relocator =
+new SimpleRelocator( "org.eclipse", "org.eclipse1234", null, null 
);
+List relocators = Lists.newArrayList( relocator 
);
+
+String content = "org.eclipse.osgi.launch.EquinoxFactory\n";
+byte[] contentBytes = content.getBytes( "UTF-8" );
+InputStream contentStream = new ByteArrayInputStream( contentBytes );
+String contentResource = 
"META-INF/services/org.osgi.framework.launch.FrameworkFactory";
+
+ServicesResourceTransformer xformer = new 
ServicesResourceTransformer();
+xformer.processResource( contentResource, contentStream, relocators );
+contentStream.close();
+
+File tempJar = File.createTempFile("shade.", ".jar");
+tempJar.deleteOnExit();
+FileOutputStream fos = new FileOutputStream( tempJar );
+JarOutputStream jos = new JarOutputStream( fos );
+try {
+xformer.modifyOutputStream( jos );
+jos.close();
+jos = null;
+JarFile jarFile = new JarFile( tempJar );
+JarEntry jarEntry = jarFile.getJarEntry( contentResource );
+assertNotNull( jarEntry );
+InputStream entryStream = jarFile.getInputStream( jarEntry );
+try {
+String xformedContent = IOUtils.toString(entryStream, "utf-8");
+assertEquals( "org.eclipse1234.osgi.launch.EquinoxFactory" + 
System.getProperty( "line.separator" ), xformedContent );
+
+} finally {
+IOUtils.closeQuietly( entryStream );
+jarFile.close();
+}
+} finally {
+if (jos != null)
+{
+IOUtils.closeQuietly( jos );
+}
+tempJar.delete();
+}
+}
 
 @Test
 public void concatenation() throws Exception {


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> shadedPattern applied multiples times when relocating the contents of 
> META-INF/services files
> 

[GitHub] rfscholte closed pull request #9: [MSHADE-291] - Fixes bug in ServicesResourceTransformer

[GitBox]

rfscholte closed pull request #9: [MSHADE-291] - Fixes bug in 
ServicesResourceTransformer
URL: https://github.com/apache/maven-shade-plugin/pull/9
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/pom.xml b/pom.xml
index 8fca8d3..cb10a84 100644
--- a/pom.xml
+++ b/pom.xml
@@ -78,6 +78,9 @@
 
   Anthony Dahanne
 
+
+  Fabiano Cipriano de Oliveira
+
   
 
   
diff --git 
a/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
 
b/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
index f1cb9d6..d087522 100644
--- 
a/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
+++ 
b/src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
@@ -138,20 +138,6 @@ public void modifyOutputStream( JarOutputStream jos )
 
 while ( ( className = reader.readLine() ) != null )
 {
-
-if ( relocators != null )
-{
-for ( Relocator relocator : relocators )
-{
-//if the class can be relocated then relocate it
-if ( relocator.canRelocateClass( className ) )
-{
-className = relocator.applyToSourceContent( 
className );
-break;
-}
-}
-}
-
 writer.println( className );
 writer.flush();
 }
diff --git 
a/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
 
b/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
index a9f78db..18dab2f 100644
--- 
a/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
+++ 
b/src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
@@ -89,6 +89,50 @@ public void relocatedClasses() throws Exception {
 tempJar.delete();
 }
 }
+
+@Test
+public void concatanationAppliedMultipleTimes() throws Exception {
+SimpleRelocator relocator =
+new SimpleRelocator( "org.eclipse", "org.eclipse1234", null, null 
);
+List relocators = Lists.newArrayList( relocator 
);
+
+String content = "org.eclipse.osgi.launch.EquinoxFactory\n";
+byte[] contentBytes = content.getBytes( "UTF-8" );
+InputStream contentStream = new ByteArrayInputStream( contentBytes );
+String contentResource = 
"META-INF/services/org.osgi.framework.launch.FrameworkFactory";
+
+ServicesResourceTransformer xformer = new 
ServicesResourceTransformer();
+xformer.processResource( contentResource, contentStream, relocators );
+contentStream.close();
+
+File tempJar = File.createTempFile("shade.", ".jar");
+tempJar.deleteOnExit();
+FileOutputStream fos = new FileOutputStream( tempJar );
+JarOutputStream jos = new JarOutputStream( fos );
+try {
+xformer.modifyOutputStream( jos );
+jos.close();
+jos = null;
+JarFile jarFile = new JarFile( tempJar );
+JarEntry jarEntry = jarFile.getJarEntry( contentResource );
+assertNotNull( jarEntry );
+InputStream entryStream = jarFile.getInputStream( jarEntry );
+try {
+String xformedContent = IOUtils.toString(entryStream, "utf-8");
+assertEquals( "org.eclipse1234.osgi.launch.EquinoxFactory" + 
System.getProperty( "line.separator" ), xformedContent );
+
+} finally {
+IOUtils.closeQuietly( entryStream );
+jarFile.close();
+}
+} finally {
+if (jos != null)
+{
+IOUtils.closeQuietly( jos );
+}
+tempJar.delete();
+}
+}
 
 @Test
 public void concatenation() throws Exception {


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682821#comment-16682821
 ] 

Robert Scholte commented on MNG-6511:
-

This is better, it gives the user the power to choose between strict and 
less-strict. I would prefer the elvis-operator, and would even push it a little 
bit further: -pl ?bar should also be possible. 

> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when 
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really 
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options 
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_, 
> etc.) on different hierarchy levels of larger multi module project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682798#comment-16682798
 ] 

ASF GitHub Bot commented on SUREFIRE-1593:
--

Tibor17 commented on a change in pull request #198: [SUREFIRE-1593] Correcting 
relativization logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#discussion_r232479128
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -150,10 +150,9 @@ private static String toClasspathElementUri( @Nonnull 
Path parent,
 {
 try
 {
-return new URI( null,
-parent.relativize( classPathElement.toPath() 
).toString().
-replace( File.separatorChar, '/' ),
-null ).toASCIIString();
+Path relativePath = parent.relativize( classPathElement.toPath() );
 
 Review comment:
   @jglick 
   Not sure about Vagrant but I know that Docker works with Windows 10.
   our Jenkins in ASF has Windows server 2008.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When 
> active—i.e., when the drive letters of the system temporary directory, per 
> SUREFIRE-1400, and the project basedir were the same.) It would produce 
> relative URIs containing {{%5C}} where {{/}} was intended.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682796#comment-16682796
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing and 
align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-437652947
 
 
   Force-pushed requested changes.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682795#comment-16682795
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478875
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,92 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) ) 
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" + 
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage", 
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set 
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" + 
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get( 
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " + 
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " + 
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals( 
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal - 
proceeding anyway... " );
 
 Review comment:
   It _could_. It works well without the `return` here -- the `return` would 
avoid some extra resolution work.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before 

[GitHub] Tibor17 commented on a change in pull request #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows

[GitBox]

Tibor17 commented on a change in pull request #198: [SUREFIRE-1593] Correcting 
relativization logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#discussion_r232479128
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -150,10 +150,9 @@ private static String toClasspathElementUri( @Nonnull 
Path parent,
 {
 try
 {
-return new URI( null,
-parent.relativize( classPathElement.toPath() 
).toString().
-replace( File.separatorChar, '/' ),
-null ).toASCIIString();
+Path relativePath = parent.relativize( classPathElement.toPath() );
 
 Review comment:
   @jglick 
   Not sure about Vagrant but I know that Docker works with Windows 10.
   our Jenkins in ASF has Windows server 2008.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682797#comment-16682797
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478958
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   Who can say that the versions will be always like this?
   Somebody has to watch the versions in Maven Central and still update this 
code. What if the version is not successfully resolved?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478958
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,96 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String jupiterVersion = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", jupiterVersion );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null ) // no api, no engine
+{
+return;
+}
+if ( !junit.getBaseVersion().equals( "4.12" ) ) // not "JUnit 
4.12", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
 
 Review comment:
   Who can say that the versions will be always like this?
   Somebody has to watch the versions in Maven Central and still update this 
code. What if the version is not successfully resolved?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing and 
align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-437652947
 
 
   Force-pushed requested changes.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478875
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,92 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) ) 
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" + 
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage", 
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set 
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" + 
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get( 
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " + 
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " + 
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals( 
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal - 
proceeding anyway... " );
 
 Review comment:
   It _could_. It works well without the `return` here -- the `return` would 
avoid some extra resolution work.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682794#comment-16682794
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478805
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,92 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) ) 
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" + 
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage", 
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set 
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" + 
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get( 
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " + 
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " + 
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals( 
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal - 
proceeding anyway... " );
 
 Review comment:
   If it must have `return` then keep it of course.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider 

[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478805
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
 ##
 @@ -2846,8 +2849,92 @@ public void addProviderProperties()
 @Nonnull
 public Set getProviderClasspath()
 {
+String provider = "surefire-junit-platform";
 String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath( 
"surefire-junit-platform", version );
+Set providerArtifacts = 
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set 
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get( 
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter", 
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set 
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) ) 
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get( 
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by 
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" + 
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage", 
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set 
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" + 
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get( 
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " + 
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " + 
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals( 
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal - 
proceeding anyway... " );
 
 Review comment:
   If it must have `return` then keep it of course.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682793#comment-16682793
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478774
 
 

 ##
 File path: 
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
 ##
 @@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter( 
TestIdentifier testIdentifier, Thr
 {
 String className = getClassName( testIdentifier );
 String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName, 
throwable );
 
 Review comment:
   Done.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478774
 
 

 ##
 File path: 
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
 ##
 @@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter( 
TestIdentifier testIdentifier, Thr
 {
 String className = getClassName( testIdentifier );
 String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName, 
throwable );
 
 Review comment:
   Done.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682788#comment-16682788
 ] 

ASF GitHub Bot commented on SUREFIRE-1585:
--

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478010
 
 

 ##
 File path: 
surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java
 ##
 @@ -93,12 +93,10 @@ public void platform() throws VerificationException
 String testClasspath = "[DEBUG] test(compact) classpath:"
 + "  test-classes"
 + "  classes"
-+ "  junit-jupiter-engine-" + jupiter + ".jar"
++ "  junit-jupiter-api-" + jupiter + ".jar"
 
 Review comment:
   > Do we have third option we can document with this fix?
   
   Don't think so. Will update the documentation when you approved this PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Auto-resolve "missing" JUnit 5 artifacts
> 
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
>  Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing" 
> artifacts before executing tests.
>  
> For example, the JUnit Platform Provider should add "missing" Test Engine 
> artifacts for when users only depend on the API of a test framework.
>  * User test depends on *`junit-jupiter-api`* only? Provide 
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
>  * User test depends on *`junit-jupiter-params`* only? That pulls in 
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test 
> runtime -- automatically or via plugin deps.
>  * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform 
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- 
> automatically or via plugin deps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts

[GitBox]

sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] 
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232478010
 
 

 ##
 File path: 
surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java
 ##
 @@ -93,12 +93,10 @@ public void platform() throws VerificationException
 String testClasspath = "[DEBUG] test(compact) classpath:"
 + "  test-classes"
 + "  classes"
-+ "  junit-jupiter-engine-" + jupiter + ".jar"
++ "  junit-jupiter-api-" + jupiter + ".jar"
 
 Review comment:
   > Do we have third option we can document with this fix?
   
   Don't think so. Will update the documentation when you approved this PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services