Am 2017-01-05 um 01:01 schrieb Dan Tran:
Hi,
before the canceled wagon-1.11 the suite was about 6minutes, now it is 9
min on my virtualbox centos 7, jdk 7
Is it a concern?
Can you actually tell which test exactly runs longer?
I have added to two tests a sleep for 2000 ms to avoid race cond
Am 01/04/17 um 08:44 schrieb Hervé BOUTEMY:
> Hi,
>
> I don't know how it was done (a good number of years ago) for me to have edit
> karma, but I have.
> I looked for INFRA documentation on the topic, and found related procedure I
> didn't know [1]
>
> I don't know who is the "Space Admin" for
Maybe just test if things change when running those ITs multiple times
with Maven 3.0.5 instead of 3.3.9.
Am 01/05/17 um 02:37 schrieb Christian Schulte:
> Am 01/04/17 um 20:16 schrieb Stephen Connolly:
>> https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset-master/6/testRepor
Am 01/04/17 um 20:16 schrieb Stephen Connolly:
> https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset-master/6/testReport/junit/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVTest/testitUseHttpProxyForWebDAV_2/
>
> Seems to fail at random on Windows...
>
It may be a
Hi,
before the canceled wagon-1.11 the suite was about 6minutes, now it is 9
min on my virtualbox centos 7, jdk 7
Is it a concern?
Thanks
-Dan
PS the good thing the huge http test no longer timeout on my box
+1 (committer)
Le 04/01/2017 à 13:16, Stephen Connolly a écrit :
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apach
+1 (committer)
Am 01/04/17 um 13:16 schrieb Stephen Connolly:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
>
This would be better on the discuss thread, but here is my answer anyway:
Well we want to bring most of that history back in for 3.5.1+ so, no that
wouldn't work AIUI.
Part of the issue is the to and fro with things like the bump of
modelVersion to 4.1.0 and then the revert, etc.
Plus if the com
On 5 Jan 2017, at 1:16, Stephen Connolly wrote:
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
You _could_ branch at the point you want to reset to, then use an ours/theirs
merge strategy which creates a merge commit t
We don't delete them. We can mark them as skipped using the range
facilities of the integration tests
Integration tests should be mostly append only.
There are some rare cases were an existing test needs modification. Those
should be handled as RTC
There are more cases where we may decide to cha
Sounds reasonable. This applies to a lot of tests. There are also a
bunch of tests which apply to Maven 2.x only. I see no reason to keep
them around.
Michael
Am 2017-01-04 um 21:26 schrieb Stephen Connolly:
Then we should use ranges to disable for newer Maven and create a new test
with a ran
Then we should use ranges to disable for newer Maven and create a new test
with a range enabling for the new mavens
On Wed 4 Jan 2017 at 19:46, Michael Osipov wrote:
> Am 2017-01-04 um 20:27 schrieb Stephen Connolly:
>
> > perhaps, but we need to be careful about changing ITs
>
>
>
> This being
Github user michael-o commented on the issue:
https://github.com/apache/maven-wagon/pull/18
One could also consider merging both and differentiate only by the URL, if
this is possible.
---
If your project is set up for it, you can reply to this email and have your
reply appear on Git
Github user michael-o commented on the issue:
https://github.com/apache/maven-wagon/pull/18
Is this a complete replacement for Jackrabbit for the Wagon provider?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your pro
Am 2017-01-04 um 20:27 schrieb Stephen Connolly:
perhaps, but we need to be careful about changing ITs
This being true, but having tests rely on a very old extension version
does not reflect reality. Consider that the Wagon version in Maven is
2.10 but the extension in 2.0. Looks awkward to
perhaps, but we need to be careful about changing ITs
On 4 January 2017 at 19:22, Michael Osipov wrote:
> Am 2017-01-04 um 20:16 schrieb Stephen Connolly:
>
>> https://builds.apache.org/view/Maven/job/maven-jenkinsfile/
>> job/post-reset-master/6/testReport/junit/org.apache.
>> maven.it/MavenITm
Am 2017-01-04 um 20:16 schrieb Stephen Connolly:
https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset-master/6/testReport/junit/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVTest/testitUseHttpProxyForWebDAV_2/
I have seen this somewhere else already...the Wagon ver
https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset-master/6/testReport/junit/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVTest/testitUseHttpProxyForWebDAV_2/
Seems to fail at random on Windows...
+1 (PMC & committer)
Am 2017-01-04 um 13:16 schrieb Stephen Connolly:
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
A
Am 2017-01-04 um 10:06 schrieb Stephen Connolly:
On 31 December 2016 at 20:10, Stephen Connolly
I have updated the tracking of these issues previously without a JIRA:
MNG- WONTFIX Removing redundant test
This is part of MNG-5977
MNG- WONTFIX updated code to matc
I am fine with that. Though, I have changed tests to 2.12. This might
justify 2.12, but I am open to either one.
Michael
Am 2017-01-04 um 10:36 schrieb Dan Tran:
I would vote for 2.11.1 same practice at maven core
-Dan
On Wed, Jan 4, 2017 at 1:22 AM, Michael Osipov <1983-01...@gmx.net> wrot
+1 (committer)
Stephen Connolly wrote on 2017-01-04 04:16:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
> A
+1
On Jan 4, 2017 10:03 AM, "Robert Scholte" wrote:
> +1
>
> On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi,
>>
>> We have collectively managed to mess up our ability to follow the original
>> release plan for 3.4.0 which was originally su
+1
On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly
wrote:
Hi,
We have collectively managed to mess up our ability to follow the
original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration
t
+1
--
Regards,
Igor
On Wed, Jan 4, 2017, at 08:31 AM, Andreas Gudian wrote:
> +1
>
>
> Anders Hammar schrieb am Mi. 4. Jan. 2017 um 13:22:
>
> > +1
> >
> >
> >
> > /Anders
> >
> >
> >
> > On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
>
+1
Anders Hammar schrieb am Mi. 4. Jan. 2017 um 13:22:
> +1
>
>
>
> /Anders
>
>
>
> On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> wrote:
>
>
>
> > Hi,
>
> >
>
> > We have collectively managed to mess up our ability to follow the
> original
>
> > release
+1
/Anders
On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's
+1 (PMC & committer)
On Wed 4 Jan 2017 at 12:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Ecli
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apache's Maven Resolver plus some other orthogonal changes around logging
I would vote for 2.11.1 same practice at maven core
-Dan
On Wed, Jan 4, 2017 at 1:22 AM, Michael Osipov <1983-01...@gmx.net> wrote:
> If so, I would drop 2.11 altogether and go with 2.12.
>
> > Gesendet: Mittwoch, 04. Januar 2017 um 08:47 Uhr
> > Von: "Hervé BOUTEMY"
> > An: "Maven Developers
If so, I would drop 2.11 altogether and go with 2.12.
> Gesendet: Mittwoch, 04. Januar 2017 um 08:47 Uhr
> Von: "Hervé BOUTEMY"
> An: "Maven Developers List"
> Betreff: Re: [VOTE] Releasing Wagon 2.11 - Cancel
>
> on git, AFAIK, going to 2.11.1 seems the best practice (removing tag in
> origin
On 31 December 2016 at 20:10, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> MNG- WONTFIX Add a ProjectArtifactsCache similar to
> PluginArtifactsCache
> MNG- WONTFIX added core extensions documentation
> MNG- WONTFIX
32 matches
Mail list logo
