[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904864#comment-16904864
]
Kent Granström commented on MDEP-579:
-
Hi [~pmoerenhout]
I have now cloned your branch and build it and tested it on some artifacts we
have got and unfortunatelly it appears not to work. Due to company policy I
have had to replace certain data... sorry for that but this is what I get when
I run it: (first the updated version and den the original one)
{noformat}
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get from plugin
realm
ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@33909752]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get' with
basic configurator -->
[DEBUG] (f) artifact = com.test.note:note-docker:4.1:zip
[DEBUG] (s) packaging = jar
[DEBUG] (f) pomRemoteRepositories = [ id: nexus
url: https://example.com/nexus/repository/public-repo
layout: default
snapshots: [enabled => false, update => daily]
releases: [enabled => true, update => daily]
]
[DEBUG] (f) remoteRepositories =
internal-repo-id::default::https://example.com/nexus/repository/internal-repo
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@682bd3c4
[DEBUG] (f) skip = false
[DEBUG] (f) transitive = false
[DEBUG] -- end configuration --
[INFO] Resolving com.test.note:note-docker:zip:4.1
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://example.com/nexus/repository/public-repo
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://example.com/nexus/repository/public-repo with username=***, password=***
Downloading:
https://example.com/nexus/repository/public-repo/com/test/note/note-docker/4.1/note-docker-4.1.pom
[DEBUG] Writing tracking file
C:\Users\abcd\.m2\repository\com\test\note\note-docker\4.1\note-docker-4.1.pom.lastUpdated
[DEBUG] Skipped remote request for com.test.note:note-docker:pom:4.1, already
updated during this session.
[WARNING] The POM for com.test.note:note-docker:zip:4.1 is missing, no
dependency information available
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://example.com/nexus/repository/public-repo
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://example.com/nexus/repository/public-repo with username=***, password=***
Downloading:
https://example.com/nexus/repository/public-repo/com/test/note/note-docker/4.1/note-docker-4.1.zip
[DEBUG] Writing tracking file
C:\Users\abcd\.m2\repository\com\test\note\note-docker\4.1\note-docker-4.1.zip.lastUpdated
[DEBUG] Skipped remote request for com.test.note:note-docker:zip:4.1, already
updated during this session.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 6.206 s
[INFO] Finished at: 2019-08-12T07:21:20+02:00
[INFO] Final Memory: 17M/207M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get
(default-cli) on project dummy-artifact: Couldn't download artifact: Could not
find artifact com.test.note:note-docker:zip:4.1 in nexus
(https://example.com/nexus/repository/public-repo) -> [Help 1]
ORIGINAL 3.1.1
[INFO] Resolving com.test.note:note-docker:zip:4.1
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://example.com/nexus/repository/public-repo
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://example.com/nexus/repository/public-repo with username=***, password=***
Downloading:
https://example.com/nexus/repository/public-repo/com/test/note/note-docker/4.1/note-docker-4.1.pom
[DEBUG] Writing tracking file
C:\Users\abcd\.m2\repository\com\test\note\note-docker\4.1\note-docker-4.1.pom.lastUpdated
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://example.com/nexus/repository/internal-repo
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://example.com/nexus/repository/internal-repo
Downloading:
https://example.com/nexus/repository/internal-repo/com/test/note/note-docker/4.1/note-docker-4.1.pom
[DEBUG] Writing tracking file
C:\Users\abcd\.m2\repository\com\test\note\note-docker\4.1\note-docker-4.1.pom.lastUpdated
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 5.162 s
[INFO] Finished at: 2019-08-12T07:26:33+02:00
[INFO] Final Memory: 17M/168M
[INFO]
[ERROR] Failed to
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904845#comment-16904845 ] Hudson commented on MRESOLVER-7: Build succeeded in Jenkins: Maven TLP » maven-resolver » pre-MRESOLVER-92 #2 See https://builds.apache.org/job/maven-box/job/maven-resolver/job/pre-MRESOLVER-92/2/ > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SUREFIRE-1553) @Unroll forces usage of JUnit Vintage
[
https://issues.apache.org/jira/browse/SUREFIRE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904806#comment-16904806
]
Clark Perkins commented on SUREFIRE-1553:
-
Also I just looked at the TEST-com.skrser.surefire.CalculatorTest.xml file -
and it's missing the test names:
{noformat}
{noformat}
> @Unroll forces usage of JUnit Vintage
> -
>
> Key: SUREFIRE-1553
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1553
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Sergey Skryabin
>Assignee: Tibor Digana
>Priority: Major
>
> If run
> {code}mvn clean test{code}
> JUnit4 tests and Spock tests (which not contain @Unroll) are executed
> normally. Once Spock test with @Unroll annotation appears, then Surefire
> execute
> {code}[INFO] Running JUnit Vintage{code}
> and all other JUnit4 tests and Spock tests are wrapped with this runner.
> In surefire-reports I see _TEST- @Unroll>.xml_ s and than
> _TEST-JUnit Vintage.xml_
> Though it could be done by intention, behaviour is different from 2.21.0 (no
> wrapping with Vintage). Also it much more visible to have separate reports
> per test class (both in console output and surefire-reports folder).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (SUREFIRE-1553) @Unroll forces usage of JUnit Vintage
[
https://issues.apache.org/jira/browse/SUREFIRE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904805#comment-16904805
]
Clark Perkins commented on SUREFIRE-1553:
-
[~tibordigana]
I just pulled down maven-surefire master, and ran the sample
maven-surefire-unroll repo against it, with the following output:
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running com.skrser.surefire.CalculatorTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 s
- in com.skrser.surefire.CalculatorTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
$ ls target/surefire-reports/
TEST-com.skrser.surefire.CalculatorTest.xml
com.skrser.surefire.CalculatorTest.txt
All the tests for CalculatorSpockTest seem to have been counted towards
CalculatorTest, which is still not desired.
I'm using maven 3.6.1 on macOS with java 1.8.0_202 if that helps.
The commit hash I built on maven-surefire was
a2a5d120c0bf0fe2f82408d5979abad8a360175c
> @Unroll forces usage of JUnit Vintage
> -
>
> Key: SUREFIRE-1553
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1553
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Sergey Skryabin
>Assignee: Tibor Digana
>Priority: Major
>
> If run
> {code}mvn clean test{code}
> JUnit4 tests and Spock tests (which not contain @Unroll) are executed
> normally. Once Spock test with @Unroll annotation appears, then Surefire
> execute
> {code}[INFO] Running JUnit Vintage{code}
> and all other JUnit4 tests and Spock tests are wrapped with this runner.
> In surefire-reports I see _TEST- @Unroll>.xml_ s and than
> _TEST-JUnit Vintage.xml_
> Though it could be done by intention, behaviour is different from 2.21.0 (no
> wrapping with Vintage). Also it much more visible to have separate reports
> per test class (both in console output and surefire-reports folder).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MPLUGINTESTING-63) AbstractMojoTestCase should return correct type
[
https://issues.apache.org/jira/browse/MPLUGINTESTING-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904745#comment-16904745
]
Robert Scholte commented on MPLUGINTESTING-63:
--
In that case we should read the generated plugin descriptor. And that is
actually better because it contains the eventually truth.
> AbstractMojoTestCase should return correct type
> ---
>
> Key: MPLUGINTESTING-63
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-63
> Project: Maven Plugin Testing
> Issue Type: Improvement
>Reporter: Samael Bate
>Priority: Major
>
> the _AbstractMojoTestCase_ class has numerous methods that simply return
> _Mojo._ An exmaple of which would be:
> {code:java}
> protected Mojo lookupConfiguredMojo( MavenProject project, String goal )
> throws Exception
> {
> return lookupConfiguredMojo( newMavenSession( project ),
> newMojoExecution( goal ) );
> }{code}
>
> It would be to deprecate these methods and replace them with typed
> equivelant, so the aboce would become:
> {code:java}
> protected T lookupConfiguredMojo( MavenProject project,
> Class type ){code}
> as noted by [~rfscholte] on [github PR
> 8|https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520251983],
> the name of the goal could be obtained from the Mojo's annotation
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MPLUGINTESTING-63) AbstractMojoTestCase should return correct type
[
https://issues.apache.org/jira/browse/MPLUGINTESTING-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904742#comment-16904742
]
Samael Bate commented on MPLUGINTESTING-63:
---
seems we cannot get the goal name via the annotation as _Mojo_ has
_RetentionPolicy.CLASS_ and is therefore not available at runtime.
> AbstractMojoTestCase should return correct type
> ---
>
> Key: MPLUGINTESTING-63
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-63
> Project: Maven Plugin Testing
> Issue Type: Improvement
>Reporter: Samael Bate
>Priority: Major
>
> the _AbstractMojoTestCase_ class has numerous methods that simply return
> _Mojo._ An exmaple of which would be:
> {code:java}
> protected Mojo lookupConfiguredMojo( MavenProject project, String goal )
> throws Exception
> {
> return lookupConfiguredMojo( newMavenSession( project ),
> newMojoExecution( goal ) );
> }{code}
>
> It would be to deprecate these methods and replace them with typed
> equivelant, so the aboce would become:
> {code:java}
> protected T lookupConfiguredMojo( MavenProject project,
> Class type ){code}
> as noted by [~rfscholte] on [github PR
> 8|https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520251983],
> the name of the goal could be obtained from the Mojo's annotation
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (SUREFIRE-1553) @Unroll forces usage of JUnit Vintage
[
https://issues.apache.org/jira/browse/SUREFIRE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904737#comment-16904737
]
Tibor Digana commented on SUREFIRE-1553:
[~skrser]
[~clarkperkins]
This project works as expected with Surefire {{3.0.0-SNAPSHOT}} which is our
development version of {{3.0.0-M4}} preliminarily utilized by the users.
So we can see the the reports in {{target/surefire-reports}} :
TEST-com.skrser.surefire.test.CalculatorSpockTest.xml
com.skrser.surefire.test.CalculatorSpockTest.txt
TEST-com.skrser.surefire.CalculatorTest.xml
com.skrser.surefire.CalculatorTest.txt
I will write an integration test and turn this issue from Bug to Test.
> @Unroll forces usage of JUnit Vintage
> -
>
> Key: SUREFIRE-1553
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1553
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Sergey Skryabin
>Assignee: Tibor Digana
>Priority: Major
>
> If run
> {code}mvn clean test{code}
> JUnit4 tests and Spock tests (which not contain @Unroll) are executed
> normally. Once Spock test with @Unroll annotation appears, then Surefire
> execute
> {code}[INFO] Running JUnit Vintage{code}
> and all other JUnit4 tests and Spock tests are wrapped with this runner.
> In surefire-reports I see _TEST- @Unroll>.xml_ s and than
> _TEST-JUnit Vintage.xml_
> Though it could be done by intention, behaviour is different from 2.21.0 (no
> wrapping with Vintage). Also it much more visible to have separate reports
> per test class (both in console output and surefire-reports folder).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (SUREFIRE-1553) @Unroll forces usage of JUnit Vintage
[
https://issues.apache.org/jira/browse/SUREFIRE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1553:
--
Assignee: Tibor Digana
> @Unroll forces usage of JUnit Vintage
> -
>
> Key: SUREFIRE-1553
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1553
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Sergey Skryabin
>Assignee: Tibor Digana
>Priority: Major
>
> If run
> {code}mvn clean test{code}
> JUnit4 tests and Spock tests (which not contain @Unroll) are executed
> normally. Once Spock test with @Unroll annotation appears, then Surefire
> execute
> {code}[INFO] Running JUnit Vintage{code}
> and all other JUnit4 tests and Spock tests are wrapped with this runner.
> In surefire-reports I see _TEST- @Unroll>.xml_ s and than
> _TEST-JUnit Vintage.xml_
> Though it could be done by intention, behaviour is different from 2.21.0 (no
> wrapping with Vintage). Also it much more visible to have separate reports
> per test class (both in console output and surefire-reports folder).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-plugin-testing] SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0
SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520254051 @rfscholte I've created https://issues.apache.org/jira/browse/MPLUGINTESTING-63 for that. My local changes were to simply move the cast into your code for now. I'll take a look at extracting it from the Mojo annotation, probably later this week. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MPLUGINTESTING-63) AbstractMojoTestCase should return correct type
Samael Bate created MPLUGINTESTING-63:
-
Summary: AbstractMojoTestCase should return correct type
Key: MPLUGINTESTING-63
URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-63
Project: Maven Plugin Testing
Issue Type: Improvement
Reporter: Samael Bate
the _AbstractMojoTestCase_ class has numerous methods that simply return
_Mojo._ An exmaple of which would be:
{code:java}
protected Mojo lookupConfiguredMojo( MavenProject project, String goal )
throws Exception
{
return lookupConfiguredMojo( newMavenSession( project ), newMojoExecution(
goal ) );
}{code}
It would be to deprecate these methods and replace them with typed equivelant,
so the aboce would become:
{code:java}
protected T lookupConfiguredMojo( MavenProject project,
Class type ){code}
as noted by [~rfscholte] on [github PR
8|https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520251983],
the name of the goal could be obtained from the Mojo's annotation
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-plugin-testing] rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0
rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520251983 > protected T lookupMojo( String goal, String pluginPom, Class type) This is just moving the cast to an argument. If you really want to change this, you should change it to protected T lookupMojo( Class type, String pluginPom ) and extract the name (=goal) from its Mojo Annotation. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0
SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520249073 done This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MPLUGINTESTING-62) target maven 3.6.0 API
Samael Bate created MPLUGINTESTING-62: - Summary: target maven 3.6.0 API Key: MPLUGINTESTING-62 URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62 Project: Maven Plugin Testing Issue Type: Improvement Reporter: Samael Bate To get this plugin working well with more recent versions of Maven (and Java) it makes sense to do this and MPLUGINTESTING-61 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-plugin-testing] Tibor17 commented on issue #8: target Java 8 and maven 3.6.0
Tibor17 commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520247649 @SingingBush regarding this PR, there are rules to first issue a new Jira tickets, see https://issues.apache.org/jira/browse/MPLUGINTESTING and then write name of PR in the form `[MPLUGINTESTING-12345] Jira title` and squash/revert commits into one commit with commit name again `[MPLUGINTESTING-12345] Jira title`. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] Tibor17 commented on issue #8: target Java 8 and maven 3.6.0
Tibor17 commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520247443 @SingingBush Let's separate the purpose of https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520244222 in a new PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MPOM-222) update target JDK from 6 to 8
[ https://issues.apache.org/jira/browse/MPOM-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904703#comment-16904703 ] Robert Scholte commented on MPOM-222: - Java 7 makes sense, it is also the lowest possible version to compile with withe latest JDK (12 / 13ea). We prefer people to explicitly set the value for source/target/release themselves, otherwise one could get a lot of suprises by simply upgrading the parent > update target JDK from 6 to 8 > - > > Key: MPOM-222 > URL: https://issues.apache.org/jira/browse/MPOM-222 > Project: Maven POMs > Issue Type: Improvement >Reporter: Samael Bate >Priority: Major > > currently the maven-pom set's compiler source and compiler target to JDK 6. > Java 6 is already EOL and even 7 is old. Please just jump straight to setting > Java 8 as the target. Otherwise all the projects that inherit it are stuck > trying to support jdk 6, 7, 8, 9, 10, 11, 12, and 13 which is bound to be a > burden. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-plugin-testing] SingingBush commented on issue #8: target Java 8 and maven 3.6.0
SingingBush commented on issue #8: target Java 8 and maven 3.6.0
URL:
https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520244222
Yes the update is just so that this plugin can work with newer code bases
not because of requirements in the code. I'm currently working on a maven
plugin and found this plugin troublesome because I use latest maven and Java.
There's some other changes I'd like to submit but wanted to see what happens
with this first. For example, I'd like to change methods such as this:
```java
protected Mojo lookupMojo( String goal, String pluginPom )
throws Exception
{
return lookupMojo( goal, new File( pluginPom ) );
}
```
to this:
```java
protected T lookupMojo( String goal, String pluginPom,
Class type)
throws Exception
{
return type.cast(lookupMojo(goal, new File(pluginPom)));
}
```
perhaps leaving the old version with `@Deprecated`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] (MPOM-222) update target JDK from 6 to 8
[ https://issues.apache.org/jira/browse/MPOM-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904698#comment-16904698 ] Michael Osipov commented on MPOM-222: - Java 7 would be reasonable for now. [~rfscholte]. > update target JDK from 6 to 8 > - > > Key: MPOM-222 > URL: https://issues.apache.org/jira/browse/MPOM-222 > Project: Maven POMs > Issue Type: Improvement >Reporter: Samael Bate >Priority: Major > > currently the maven-pom set's compiler source and compiler target to JDK 6. > Java 6 is already EOL and even 7 is old. Please just jump straight to setting > Java 8 as the target. Otherwise all the projects that inherit it are stuck > trying to support jdk 6, 7, 8, 9, 10, 11, 12, and 13 which is bound to be a > burden. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-plugin-testing] rfscholte commented on issue #8: target Java 8 and maven 3.6.0
rfscholte commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520241692 Looking at the code I see: generics (Java5), @Override on inherited interface methods (Java6). I don't see any changes that require a newer version of Java or Maven API. However, 7 is the new minimum, otherwise we can't test it with Java 12 and 13. That would also make it possible to apply: try-with-resources, diamond operators. As you might have noticed: upgrading is more than changing numbers in the pom. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] SingingBush edited a comment on issue #8: target Java 8 and maven 3.6.0
SingingBush edited a comment on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520239859 ok, I'm going to undo the JDK and junit change so that the PR is purely about changes needed to target the maven 3.6.0 API edit: seems that's going to require JDK 7 as minimum, so will include that. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] SingingBush commented on issue #8: target Java 8 and maven 3.6.0
SingingBush commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520239859 ok, I'm going to undo the JDK and junit change so that the PR is purely about changes needed to target the maven 3.6.0 API This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (SUREFIRE-1687) Incorrect test count displayed with Maven Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1687.
--
Resolution: Duplicate
Assignee: Tibor Digana
We are aware of such issues where the users run parallel JUnit5 tests. It has
affected the test summary and the log files too. This is a bigger fix since we
have to change principal implementation in the project. We would like to cut
the version 3.0.0-M4 in August and postpone SUREFIRE-1643 to M5.
> Incorrect test count displayed with Maven Surefire
> --
>
> Key: SUREFIRE-1687
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1687
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Priyank Shah
>Assignee: Tibor Digana
>Priority: Major
>
> Steps to reproduce
> - Run code from [https://github.com/priyankshah217/junit5sample]
> - It has running strategy concurrent (method and class level)
>
> {code:java}
> junit.jupiter.execution.parallel.mode.default = concurrent
> junit.jupiter.execution.parallel.mode.classes.default = concurrent{code}
> - Run test using
> {code:java}
> mvn clean test{code}
> *Actual Output*
>
> {code:java}
> [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.026
> s - in SampleTest2
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.04
> s - in SampleTest{code}
> [https://gist.github.com/priyankshah217/c8860393e82eb18172e6bd2afda5957e#file-junit5executionlog]
> *Expected Output*
> {code:java}
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.026
> s - in SampleTest2
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.04
> s - in SampleTest{code}
>
> *Context*
> - Used versions (Jupiter/Vintage/Platform):
> junit-jupiter-engine:5.5.1,junit-platform-runner:1.5.1
> - Build Tool/IDE: mvn:3.6.1
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-plugin-testing] Tibor17 commented on issue #8: target Java 8 and maven 3.6.0
Tibor17 commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520238398 Our major goal is to release Maven 3.6.x. I do not know when Java 1.8 would be in Maven and I have not noticed any brainstorming, plan and email discussion with the whole team. I have noticed one Jira issue regarding Java 1.8 but I would say making such a change in the incremental version 3.6.2 is more unexpected step than in the version 3.7.0 or 4.0.0. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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-376) Change default source/target to 1.7 (new minimum for JDK 12)
[ https://issues.apache.org/jira/browse/MCOMPILER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904679#comment-16904679 ] Samael Bate commented on MCOMPILER-376: --- The JDK is moving far quicker than tooling. The compiler plugin should jump straight to Java 8 as minimum. It's been years since I've needed to work on a project that didn't use at least JDK 8 and anyone that needs older is already covered by current releases. If the compiler plugin jumps to JDK8 as minimum for next release or 2 then jumps to JDK 11 that would be ideal. Just keep to the LTS versions. > Change default source/target to 1.7 (new minimum for JDK 12) > > > Key: MCOMPILER-376 > URL: https://issues.apache.org/jira/browse/MCOMPILER-376 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > > With the statement "It must be possible to build a Hello World application > with the latest JDK + latest Maven + minimum pom" the default value for > source+target must be lifted to 1.7 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-plugin-testing] SingingBush commented on issue #8: target Java 8 and maven 3.6.0
SingingBush commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520236882 All three aspects of the PR could be viewed that way. Is there a specific part that's concerning; JDK version, mvn version, or junit change? I don't mind making changes. Just updating the targeted maven version would be good. I do think that ASF shoud start targeting JDK 8 (even 7 would be an improvement over trying to support 6 through 13) but that should be in the parent pom, as per [MPOM-222](https://issues.apache.org/jira/browse/MPOM-222). This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MPOM-222) update target JDK from 6 to 8
Samael Bate created MPOM-222: Summary: update target JDK from 6 to 8 Key: MPOM-222 URL: https://issues.apache.org/jira/browse/MPOM-222 Project: Maven POMs Issue Type: Improvement Reporter: Samael Bate currently the maven-pom set's compiler source and compiler target to JDK 6. Java 6 is already EOL and even 7 is old. Please just jump straight to setting Java 8 as the target. Otherwise all the projects that inherit it are stuck trying to support jdk 6, 7, 8, 9, 10, 11, 12, and 13 which is bound to be a burden. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MPLUGINTESTING-61) Require Java 7
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904677#comment-16904677 ] Samael Bate commented on MPLUGINTESTING-61: --- I'd agrue that 8 should now be the minimum. > Require Java 7 > -- > > Key: MPLUGINTESTING-61 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-61 > Project: Maven Plugin Testing > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904652#comment-16904652 ] Tibor Digana commented on MRESOLVER-92: --- [~michael-o] Please make a review and I will squash the changes in one commit. Then we can push it to master and start the release of 1.4.1. Later we have to agree on the concept of resolving the dependencies in parallel in another version. > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Assignee: Tibor Digana >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 introduced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904650#comment-16904650 ] Tibor Digana commented on MRESOLVER-92: --- [~michael-o] Done. The local build is successful. Reverted the status to before MRESOLVER-7 with respect of what has been done by Sylwester regarding upgrade the code to Java 1.7 features. > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Assignee: Tibor Digana >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 introduced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (MSHARED-391) org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository does not understand mirrors
[ https://issues.apache.org/jira/browse/MSHARED-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHARED-391. -- Resolution: Auto Closed Assignee: Robert Scholte The shared component maven-repository-builder has been retired, so this issue won't be fixed. > org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository > does not understand mirrors > --- > > Key: MSHARED-391 > URL: https://issues.apache.org/jira/browse/MSHARED-391 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-repository-builder (RETIRED) >Reporter: Kristian Rosenvold >Assignee: Robert Scholte >Priority: Major > > The method should search getMirroredRepositories() for mirrors too. > Unfortunately this method appeared in 3.0.3, so we need to establish a new > minimum to fix this -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned MRESOLVER-92: - Assignee: Tibor Digana > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Assignee: Tibor Digana >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 introduced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[
https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904625#comment-16904625
]
Michael Osipov commented on MRESOLVER-92:
-
I didn't commit anything because {{git revert}} required me to resolve
conflicts locally first.
> Revert MRESOLVER-7
> --
>
> Key: MRESOLVER-92
> URL: https://issues.apache.org/jira/browse/MRESOLVER-92
> Project: Maven Resolver
> Issue Type: Task
> Components: resolver
>Affects Versions: 1.4.0
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 1.4.1
>
>
> MRESOLVER-7 introduced subtile bugs which need to be fixed first.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904622#comment-16904622 ] Tibor Digana commented on MRESOLVER-92: --- So push your local commits and we will squash all your/mine commits in one. > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 introduced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904621#comment-16904621 ] Michael Osipov commented on MRESOLVER-92: - No, no changes yet. I tried locally, but had several conflicts which require some time to resolve. If you want to work on it, please assign it to you. I'd be glad to review. > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 intruced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-92: Description: MRESOLVER-7 introduced subtile bugs which need to be fixed first. (was: MRESOLVER-7 intruced subtile bugs which need to be fixed first.) > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 introduced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRESOLVER-92) Revert MRESOLVER-7
[ https://issues.apache.org/jira/browse/MRESOLVER-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904619#comment-16904619 ] Tibor Digana commented on MRESOLVER-92: --- [~michael-o] Very good step! I have checked out your branch. There is no changes yet? So we can start working on it. Do you agree? > Revert MRESOLVER-7 > -- > > Key: MRESOLVER-92 > URL: https://issues.apache.org/jira/browse/MRESOLVER-92 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: 1.4.0 >Reporter: Michael Osipov >Priority: Major > Fix For: 1.4.1 > > > MRESOLVER-7 intruced subtile bugs which need to be fixed first. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MDEP-658) Send dependency tree output to HTTP endpoints
[ https://issues.apache.org/jira/browse/MDEP-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEP-658: Fix Version/s: wontfix-candidate > Send dependency tree output to HTTP endpoints > - > > Key: MDEP-658 > URL: https://issues.apache.org/jira/browse/MDEP-658 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Affects Versions: 3.1.1 >Reporter: Esteban Cristóbal Rodríguez >Priority: Minor > Fix For: wontfix-candidate > > > Apart from writing the dependency tree on console or in a file, it would be > useful if it could be sent over HTTP to be processed by a third-party > service, such a ELK stack or some other tool that could process it. > After a quick overview of the source code, it seems that the following task > should be made to implement this enhancement: > * Define a new property to store the service URL. > * Apply the Strategy and Abstract Factory design patterns to implement in an > extensible way the runtime selection of dependency tree output. > * Define properties to store authentication data required by HTTP endpoints. > * Implement support for HTTP authentication: basic on a first step, and > OAuth2 later on. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-plugin-testing] michael-o closed pull request #3: Update ResolverExpressionEvaluatorStub.java
michael-o closed pull request #3: Update ResolverExpressionEvaluatorStub.java URL: https://github.com/apache/maven-plugin-testing/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] michael-o commented on issue #8: target Java 8 and maven 3.6.0
michael-o commented on issue #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-520219804 Thank you for the PR, but you wasted your time. Most of the changes will be rejected. You can refactor your code to submit non-intrusive changes only. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-plugin-testing] SingingBush opened a new pull request #8: target Java 8 and maven 3.6.0
SingingBush opened a new pull request #8: target Java 8 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8 pretty frustrating that in 2019 people are still targeting ancient Java versions. In this pull request I've set JDK 8 as the target and also updated to a more recent maven api level and updated junit to the newer `org.junit.vintage:junit-vintage-engine` equivelant. Any change of a new release? 3.3.0 was released years ago This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-wagon] eolivelli commented on issue #55: Wagon-566
eolivelli commented on issue #55: Wagon-566 URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-520217781 We will test automatically against java7,8,11 and 13, win and linux This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-wagon] eolivelli commented on issue #55: Wagon-566
eolivelli commented on issue #55: Wagon-566 URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-520217810 Ok for the test This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-wagon] michael-o commented on issue #55: Wagon-566
michael-o commented on issue #55: Wagon-566 URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-520210326 Yes, I think this will be sufficient. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (WAGON-565) Do not skip retry on SSLException by default
[
https://issues.apache.org/jira/browse/WAGON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904593#comment-16904593
]
Michael Osipov commented on WAGON-565:
--
Thanks for the explantion. As far as I understand JDK-8214339 this has been
already addressed in several builds. [~rymdkapsel], can you verify that this
has been fixed in the mentioned builds? What is your exact Java version?
> Do not skip retry on SSLException by default
>
>
> Key: WAGON-565
> URL: https://issues.apache.org/jira/browse/WAGON-565
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Martin Furmanski
>Priority: Minor
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The SSL stack in Java will transform any transport error into an
> SSLException, so it is very bad to skip retries for this entire class of
> exceptions. Transport errors are probably the number one reason why retries
> are needed, so it defeats the purpose for any secure deployments using HTTPS.
> {code:java}
> Caused by: javax.net.ssl.SSLProtocolException: Connection reset
> at sun.security.ssl.Alert.createSSLException (Alert.java:126)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:321)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:264)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:259)
> at sun.security.ssl.SSLSocketImpl.handleException (SSLSocketImpl.java:1314)
> at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:839)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
> (SessionInputBufferImpl.java:137)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
> (SessionInputBufferImpl.java:153)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine
> (SessionInputBufferImpl.java:280)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:138)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:56)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse
> (AbstractMessageParser.java:259)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader
> (DefaultBHttpClientConnection.java:163)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader
> (CPoolProxy.java:157)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse
> (HttpRequestExecutor.java:273)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:125)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
> (RedirectExec.java:110)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
> (InternalHttpClient.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:958)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1117)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1094)
> at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> {code}
> I realise this is the default of the HTTP client, but changing that library
> is just too wide of a change in a patch, but for the maven wagon it sounds
> quite safe and should help many people which experience this in their
> deployments. The alternative is that everyone using HTTPS has to track down
> this issue and tweak their configs.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
