On 7 Jul 2017, at 13:34, Mark Derricutt wrote:
> when running out of Maven 3.5. Odd thing is - it happened 3 times, and now I
> can't reproduce it. Bizarre...
Actually can reproduce it all the time down, I was running my build in slightly
different ways between tests, when adding -U to for SNAP
On 7 Jul 2017, at 8:47, Michael Osipov wrote:
>
> Release Notes - Maven Resolver - Version Maven Artifact Resolver 1.1.0
> ** Bug
> * [MRESOLVER-13] - Exceptions are suppressed incorrectly when closing
> resources fails
> * [MRESOLVER-19] - DefaultRepositorySystem resolveDependencies() ca
On 7 Jul 2017, at 8:47, Michael Osipov wrote:
>
> Release Notes - Maven Resolver - Version Maven Artifact Resolver 1.1.0
> ** Bug
> * [MRESOLVER-13] - Exceptions are suppressed incorrectly when closing
> resources fails
> * [MRESOLVER-19] - DefaultRepositorySystem resolveDependencies() ca
GitHub user hgschmie opened a pull request:
https://github.com/apache/maven-plugins/pull/121
Adds "failOnWarning" tests
Support for "failOnWarning" was added in the 3.6.0 release. This is mostly
unit and integration testing for the flag that I still had lying around. Would
be a sha
The Apache Maven team is pleased to announce the release of the Maven
Resolver version 1.1.0.
This module generates browsable HTML pages from Java source code.
https://maven.apache.org/resolver/
Release Notes - Maven Resolver - Version Maven Artifact Resolver 1.1.0
** Bug
* [MRESOLVER-13]
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/154
@Tibor17 awesome. Thank you for the feedback. Waiting for the merge to
continue work.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub a
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/125
The change looks reasonable but I don't use built-in multithreaded build
support myself and do not feel comfortable merging this change without proper
testing. I will have to defer to somebody more
My bad - sorry.
On Thu, Jul 6, 2017 at 7:34 AM, Michael Osipov wrote:
> Am 2017-07-06 um 13:16 schrieb Paul Hammant:
>
>> For something that's 500MB in size (random binary data) I'm experiencing
>> commits taking
>> 10x longer than a straight copy to the drive the Svn repo is on.
>>
>> Both timi
Am 2017-07-06 um 13:16 schrieb Paul Hammant:
For something that's 500MB in size (random binary data) I'm experiencing
commits taking
10x longer than a straight copy to the drive the Svn repo is on.
Both timings are on the same Ubuntu 17.04 machine, with the boot drive
being the starting position
Hi Benedikt,
I did not forget your commits.
I will merge them soon.
We are struggling with native cmd and release. Every day I thought it's
been the time to go out with release version.
On Wed, Jul 5, 2017 at 2:08 PM, britter wrote:
> Github user britter commented on the issue:
>
> https://
For something that's 500MB in size (random binary data) I'm experiencing
commits taking
10x longer than a straight copy to the drive the Svn repo is on.
Both timings are on the same Ubuntu 17.04 machine, with the boot drive
being the starting position of the 512MB file and a USB3 mounted 4TB
seaga
11 matches
Mail list logo