You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2017/01/11 09:54:20 UTC

The failing MNG-3599 tests

After some analysis I think this is the Wagon upgrade to 2.10 in Maven 3.3.9

I have created a mng-3599 branch in maven-integration-tests with my
proposed fix (namely deactivate the old test from 3.3.9 onwards and
duplicate with a new test for 3.3.9 onwards

I have committed a throw-away branch in maven-core called mng-3599 with the
Jenkinsfile pointing at the mng-3599 integration tests...

Let's see if that fixes our test for us:
https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/

Re: The failing MNG-3599 tests

Posted by Christian Schulte <cs...@schulte.it>.
Am 01/12/17 um 01:32 schrieb Stephen Connolly:
> Well now after several repeats still no sign of the failure when running
> with -llr

Would be great if it has become reproducible by that. I wonder why it
succeeded several times without that change. What so ever. All it needs
is to stop failing every other run.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
Merged

On 13 January 2017 at 13:43, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> https://github.com/apache/maven-integration-testing/commit/
> 6c86dc6fe8bad24950fa76d295910e7d7e145a21 is the diff I am proposing
> (we'll know in 2 hours if it worked on a full test run)
>
> On 13 January 2017 at 13:28, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/6/ is a
>> full build run with my proposed fix to MNG-6155
>>
>> On 13 January 2017 at 13:25, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> Yep... looks like that's the real fix
>>>
>>> On 13 January 2017 at 11:25, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> I have 5 builds stacked up with https://github.com/apache
>>>> /maven-integration-testing/commit/1013b7d6bf25e831860276ae68
>>>> e226134481cbb3 if
>>>>
>>>>  <settings>
>>>>     <mirrors>
>>>>       <mirror>
>>>>  -      <id>test-mirror</id>
>>>>  +      <id>central</id>
>>>>         <url>@protocol@://www.example.com/</url>
>>>>         <mirrorOf>*</mirrorOf>
>>>>       </mirror>
>>>>
>>>> works for all 5 builds then I will rebase to remove the narrowing of
>>>> the tests to just one integration test and we can see if that runs on the
>>>> full cycle and then merge and be done with MNG-6155
>>>>
>>>> On 13 January 2017 at 11:07, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which
>>>>> is just running the affected test)
>>>>>
>>>>> On 13 January 2017 at 11:03, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>>> So the problem here AIUI is that we keep metadata about when we last
>>>>>> checked the local repository against the remote.
>>>>>>
>>>>>> When you are using dav as the proxy protocol, we need the webdav
>>>>>> extension in order to check that the local repository artifacts match the
>>>>>> remote... but we have not checked the webdav extension itself... so without
>>>>>> -llr maven tries to check the content for validity *before* it has enabled
>>>>>> the extension and consequently there is no dav protocol and it cannot check
>>>>>>
>>>>>> with -llr we skip the checking of the content against the remote.
>>>>>>
>>>>>> If we ran the test in off-line mode then we would also skip the
>>>>>> test... but we cannot do that as the whole point of the test is to run in
>>>>>> on-line mode
>>>>>>
>>>>>> What we really want to do is run a dummy project first with no proxy
>>>>>> but enabling the webdav extension (that will create the markers) *and then*
>>>>>> we can run the real project.
>>>>>>
>>>>>> I wonder if the issue is that we have a different id on the mirror:
>>>>>>
>>>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>>>> ter/core-it-suite/src/test/resources/mng-3599-mk2/settings-t
>>>>>> emplate.xml#L4
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>>>> ter/core-it-suite/src/test/resources-filtered/settings.xml#L34
>>>>>>
>>>>>> If we gave the mirror the id of "central" could we remove llr?
>>>>>>
>>>>>> I shall take a test to see!
>>>>>>
>>>>>> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Just to be sure:
>>>>>>> MNG-3599 is about "webdav does not set http-proxy correctly"
>>>>>>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>>>>>>> skipping some checks done when working with the default local repository.
>>>>>>> I don't see any relationship, in which case the test adjustment is
>>>>>>> fine for now.
>>>>>>> However, it would still be better if we didn't need this flag.
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>
>>>>>>> Well now after several repeats still no sign of the failure when
>>>>>>>> running
>>>>>>>> with -llr
>>>>>>>>
>>>>>>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>>>>>>
>>>>>>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>>>>>>> /4/testReport/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you re-run the test on windows multiple times? The failure has
>>>>>>>>> not
>>>>>>>>>
>>>>>>>>> been reproducible so far. It succeeds a couple of times, then
>>>>>>>>> fails a
>>>>>>>>>
>>>>>>>>> couple of times, then succeeds again without anything having
>>>>>>>>> changed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>> Sent from my phone
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
https://github.com/apache/maven-integration-testing/commit/6c86dc6fe8bad24950fa76d295910e7d7e145a21
is the diff I am proposing (we'll know in 2 hours if it worked on a full
test run)

On 13 January 2017 at 13:28, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/6/ is a full
> build run with my proposed fix to MNG-6155
>
> On 13 January 2017 at 13:25, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Yep... looks like that's the real fix
>>
>> On 13 January 2017 at 11:25, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> I have 5 builds stacked up with https://github.com/apache
>>> /maven-integration-testing/commit/1013b7d6bf25e831860276ae68
>>> e226134481cbb3 if
>>>
>>>  <settings>
>>>     <mirrors>
>>>       <mirror>
>>>  -      <id>test-mirror</id>
>>>  +      <id>central</id>
>>>         <url>@protocol@://www.example.com/</url>
>>>         <mirrorOf>*</mirrorOf>
>>>       </mirror>
>>>
>>> works for all 5 builds then I will rebase to remove the narrowing of the
>>> tests to just one integration test and we can see if that runs on the full
>>> cycle and then merge and be done with MNG-6155
>>>
>>> On 13 January 2017 at 11:07, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which
>>>> is just running the affected test)
>>>>
>>>> On 13 January 2017 at 11:03, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> So the problem here AIUI is that we keep metadata about when we last
>>>>> checked the local repository against the remote.
>>>>>
>>>>> When you are using dav as the proxy protocol, we need the webdav
>>>>> extension in order to check that the local repository artifacts match the
>>>>> remote... but we have not checked the webdav extension itself... so without
>>>>> -llr maven tries to check the content for validity *before* it has enabled
>>>>> the extension and consequently there is no dav protocol and it cannot check
>>>>>
>>>>> with -llr we skip the checking of the content against the remote.
>>>>>
>>>>> If we ran the test in off-line mode then we would also skip the
>>>>> test... but we cannot do that as the whole point of the test is to run in
>>>>> on-line mode
>>>>>
>>>>> What we really want to do is run a dummy project first with no proxy
>>>>> but enabling the webdav extension (that will create the markers) *and then*
>>>>> we can run the real project.
>>>>>
>>>>> I wonder if the issue is that we have a different id on the mirror:
>>>>>
>>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>>> ter/core-it-suite/src/test/resources/mng-3599-mk2/settings-t
>>>>> emplate.xml#L4
>>>>>
>>>>> vs
>>>>>
>>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>>> ter/core-it-suite/src/test/resources-filtered/settings.xml#L34
>>>>>
>>>>> If we gave the mirror the id of "central" could we remove llr?
>>>>>
>>>>> I shall take a test to see!
>>>>>
>>>>> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Just to be sure:
>>>>>> MNG-3599 is about "webdav does not set http-proxy correctly"
>>>>>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>>>>>> skipping some checks done when working with the default local repository.
>>>>>> I don't see any relationship, in which case the test adjustment is
>>>>>> fine for now.
>>>>>> However, it would still be better if we didn't need this flag.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>
>>>>>> Well now after several repeats still no sign of the failure when
>>>>>>> running
>>>>>>> with -llr
>>>>>>>
>>>>>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>>>>>
>>>>>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>>>>>
>>>>>>>> >
>>>>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>>>>>> /4/testReport/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you re-run the test on windows multiple times? The failure has
>>>>>>>> not
>>>>>>>>
>>>>>>>> been reproducible so far. It succeeds a couple of times, then fails
>>>>>>>> a
>>>>>>>>
>>>>>>>> couple of times, then succeeds again without anything having
>>>>>>>> changed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>> Sent from my phone
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/6/ is a full
build run with my proposed fix to MNG-6155

On 13 January 2017 at 13:25, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Yep... looks like that's the real fix
>
> On 13 January 2017 at 11:25, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I have 5 builds stacked up with https://github.com/apache
>> /maven-integration-testing/commit/1013b7d6bf25e831860276a
>> e68e226134481cbb3 if
>>
>>  <settings>
>>     <mirrors>
>>       <mirror>
>>  -      <id>test-mirror</id>
>>  +      <id>central</id>
>>         <url>@protocol@://www.example.com/</url>
>>         <mirrorOf>*</mirrorOf>
>>       </mirror>
>>
>> works for all 5 builds then I will rebase to remove the narrowing of the
>> tests to just one integration test and we can see if that runs on the full
>> cycle and then merge and be done with MNG-6155
>>
>> On 13 January 2017 at 11:07, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which is
>>> just running the affected test)
>>>
>>> On 13 January 2017 at 11:03, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> So the problem here AIUI is that we keep metadata about when we last
>>>> checked the local repository against the remote.
>>>>
>>>> When you are using dav as the proxy protocol, we need the webdav
>>>> extension in order to check that the local repository artifacts match the
>>>> remote... but we have not checked the webdav extension itself... so without
>>>> -llr maven tries to check the content for validity *before* it has enabled
>>>> the extension and consequently there is no dav protocol and it cannot check
>>>>
>>>> with -llr we skip the checking of the content against the remote.
>>>>
>>>> If we ran the test in off-line mode then we would also skip the test...
>>>> but we cannot do that as the whole point of the test is to run in on-line
>>>> mode
>>>>
>>>> What we really want to do is run a dummy project first with no proxy
>>>> but enabling the webdav extension (that will create the markers) *and then*
>>>> we can run the real project.
>>>>
>>>> I wonder if the issue is that we have a different id on the mirror:
>>>>
>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>> ter/core-it-suite/src/test/resources/mng-3599-mk2/settings-t
>>>> emplate.xml#L4
>>>>
>>>> vs
>>>>
>>>> https://github.com/apache/maven-integration-testing/blob/mas
>>>> ter/core-it-suite/src/test/resources-filtered/settings.xml#L34
>>>>
>>>> If we gave the mirror the id of "central" could we remove llr?
>>>>
>>>> I shall take a test to see!
>>>>
>>>> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org>
>>>> wrote:
>>>>
>>>>> Just to be sure:
>>>>> MNG-3599 is about "webdav does not set http-proxy correctly"
>>>>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>>>>> skipping some checks done when working with the default local repository.
>>>>> I don't see any relationship, in which case the test adjustment is
>>>>> fine for now.
>>>>> However, it would still be better if we didn't need this flag.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>> Well now after several repeats still no sign of the failure when
>>>>>> running
>>>>>> with -llr
>>>>>>
>>>>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>>>>>>
>>>>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>>>>
>>>>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>>>>
>>>>>>> >
>>>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>>>>> /4/testReport/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Can you re-run the test on windows multiple times? The failure has
>>>>>>> not
>>>>>>>
>>>>>>> been reproducible so far. It succeeds a couple of times, then fails a
>>>>>>>
>>>>>>> couple of times, then succeeds again without anything having changed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>> Sent from my phone
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
Yep... looks like that's the real fix

On 13 January 2017 at 11:25, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I have 5 builds stacked up with https://github.com/
> apache/maven-integration-testing/commit/1013b7d6bf25e831860276ae68e226
> 134481cbb3 if
>
>  <settings>
>     <mirrors>
>       <mirror>
>  -      <id>test-mirror</id>
>  +      <id>central</id>
>         <url>@protocol@://www.example.com/</url>
>         <mirrorOf>*</mirrorOf>
>       </mirror>
>
> works for all 5 builds then I will rebase to remove the narrowing of the
> tests to just one integration test and we can see if that runs on the full
> cycle and then merge and be done with MNG-6155
>
> On 13 January 2017 at 11:07, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which is
>> just running the affected test)
>>
>> On 13 January 2017 at 11:03, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> So the problem here AIUI is that we keep metadata about when we last
>>> checked the local repository against the remote.
>>>
>>> When you are using dav as the proxy protocol, we need the webdav
>>> extension in order to check that the local repository artifacts match the
>>> remote... but we have not checked the webdav extension itself... so without
>>> -llr maven tries to check the content for validity *before* it has enabled
>>> the extension and consequently there is no dav protocol and it cannot check
>>>
>>> with -llr we skip the checking of the content against the remote.
>>>
>>> If we ran the test in off-line mode then we would also skip the test...
>>> but we cannot do that as the whole point of the test is to run in on-line
>>> mode
>>>
>>> What we really want to do is run a dummy project first with no proxy but
>>> enabling the webdav extension (that will create the markers) *and then* we
>>> can run the real project.
>>>
>>> I wonder if the issue is that we have a different id on the mirror:
>>>
>>> https://github.com/apache/maven-integration-testing/blob/mas
>>> ter/core-it-suite/src/test/resources/mng-3599-mk2/settings-
>>> template.xml#L4
>>>
>>> vs
>>>
>>> https://github.com/apache/maven-integration-testing/blob/mas
>>> ter/core-it-suite/src/test/resources-filtered/settings.xml#L34
>>>
>>> If we gave the mirror the id of "central" could we remove llr?
>>>
>>> I shall take a test to see!
>>>
>>> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org>
>>> wrote:
>>>
>>>> Just to be sure:
>>>> MNG-3599 is about "webdav does not set http-proxy correctly"
>>>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>>>> skipping some checks done when working with the default local repository.
>>>> I don't see any relationship, in which case the test adjustment is fine
>>>> for now.
>>>> However, it would still be better if we didn't need this flag.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>> Well now after several repeats still no sign of the failure when running
>>>>> with -llr
>>>>>
>>>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>>>>>
>>>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>>>
>>>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>>>
>>>>>> >
>>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>>>> /4/testReport/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you re-run the test on windows multiple times? The failure has not
>>>>>>
>>>>>> been reproducible so far. It succeeds a couple of times, then fails a
>>>>>>
>>>>>> couple of times, then succeeds again without anything having changed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Sent from my phone
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
I have 5 builds stacked up with
https://github.com/apache/maven-integration-testing/commit/1013b7d6bf25e831860276ae68e226134481cbb3
if

 <settings>
    <mirrors>
      <mirror>
 -      <id>test-mirror</id>
 +      <id>central</id>
        <url>@protocol@://www.example.com/</url>
        <mirrorOf>*</mirrorOf>
      </mirror>

works for all 5 builds then I will rebase to remove the narrowing of the
tests to just one integration test and we can see if that runs on the full
cycle and then merge and be done with MNG-6155

On 13 January 2017 at 11:07, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which is
> just running the affected test)
>
> On 13 January 2017 at 11:03, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> So the problem here AIUI is that we keep metadata about when we last
>> checked the local repository against the remote.
>>
>> When you are using dav as the proxy protocol, we need the webdav
>> extension in order to check that the local repository artifacts match the
>> remote... but we have not checked the webdav extension itself... so without
>> -llr maven tries to check the content for validity *before* it has enabled
>> the extension and consequently there is no dav protocol and it cannot check
>>
>> with -llr we skip the checking of the content against the remote.
>>
>> If we ran the test in off-line mode then we would also skip the test...
>> but we cannot do that as the whole point of the test is to run in on-line
>> mode
>>
>> What we really want to do is run a dummy project first with no proxy but
>> enabling the webdav extension (that will create the markers) *and then* we
>> can run the real project.
>>
>> I wonder if the issue is that we have a different id on the mirror:
>>
>> https://github.com/apache/maven-integration-testing/blob/
>> master/core-it-suite/src/test/resources/mng-3599-mk2/setting
>> s-template.xml#L4
>>
>> vs
>>
>> https://github.com/apache/maven-integration-testing/blob/
>> master/core-it-suite/src/test/resources-filtered/settings.xml#L34
>>
>> If we gave the mirror the id of "central" could we remove llr?
>>
>> I shall take a test to see!
>>
>> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org> wrote:
>>
>>> Just to be sure:
>>> MNG-3599 is about "webdav does not set http-proxy correctly"
>>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>>> skipping some checks done when working with the default local repository.
>>> I don't see any relationship, in which case the test adjustment is fine
>>> for now.
>>> However, it would still be better if we didn't need this flag.
>>>
>>> Robert
>>>
>>>
>>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> Well now after several repeats still no sign of the failure when running
>>>> with -llr
>>>>
>>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>>>>
>>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>>
>>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>>
>>>>> >
>>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>>> /4/testReport/
>>>>>
>>>>>
>>>>>
>>>>> Can you re-run the test on windows multiple times? The failure has not
>>>>>
>>>>> been reproducible so far. It succeeds a couple of times, then fails a
>>>>>
>>>>> couple of times, then succeeds again without anything having changed.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>> Sent from my phone
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
https://builds.apache.org/job/maven-jenkinsfile/job/mng-6155/ (which is
just running the affected test)

On 13 January 2017 at 11:03, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> So the problem here AIUI is that we keep metadata about when we last
> checked the local repository against the remote.
>
> When you are using dav as the proxy protocol, we need the webdav extension
> in order to check that the local repository artifacts match the remote...
> but we have not checked the webdav extension itself... so without -llr
> maven tries to check the content for validity *before* it has enabled the
> extension and consequently there is no dav protocol and it cannot check
>
> with -llr we skip the checking of the content against the remote.
>
> If we ran the test in off-line mode then we would also skip the test...
> but we cannot do that as the whole point of the test is to run in on-line
> mode
>
> What we really want to do is run a dummy project first with no proxy but
> enabling the webdav extension (that will create the markers) *and then* we
> can run the real project.
>
> I wonder if the issue is that we have a different id on the mirror:
>
> https://github.com/apache/maven-integration-testing/
> blob/master/core-it-suite/src/test/resources/mng-3599-mk2/
> settings-template.xml#L4
>
> vs
>
> https://github.com/apache/maven-integration-testing/
> blob/master/core-it-suite/src/test/resources-filtered/settings.xml#L34
>
> If we gave the mirror the id of "central" could we remove llr?
>
> I shall take a test to see!
>
> On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org> wrote:
>
>> Just to be sure:
>> MNG-3599 is about "webdav does not set http-proxy correctly"
>> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
>> skipping some checks done when working with the default local repository.
>> I don't see any relationship, in which case the test adjustment is fine
>> for now.
>> However, it would still be better if we didn't need this flag.
>>
>> Robert
>>
>>
>> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> Well now after several repeats still no sign of the failure when running
>>> with -llr
>>>
>>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>>>
>>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>>
>>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>>
>>>> >
>>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>>> /4/testReport/
>>>>
>>>>
>>>>
>>>> Can you re-run the test on windows multiple times? The failure has not
>>>>
>>>> been reproducible so far. It succeeds a couple of times, then fails a
>>>>
>>>> couple of times, then succeeds again without anything having changed.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> --
>>>>
>>> Sent from my phone
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
So the problem here AIUI is that we keep metadata about when we last
checked the local repository against the remote.

When you are using dav as the proxy protocol, we need the webdav extension
in order to check that the local repository artifacts match the remote...
but we have not checked the webdav extension itself... so without -llr
maven tries to check the content for validity *before* it has enabled the
extension and consequently there is no dav protocol and it cannot check

with -llr we skip the checking of the content against the remote.

If we ran the test in off-line mode then we would also skip the test... but
we cannot do that as the whole point of the test is to run in on-line mode

What we really want to do is run a dummy project first with no proxy but
enabling the webdav extension (that will create the markers) *and then* we
can run the real project.

I wonder if the issue is that we have a different id on the mirror:

https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3599-mk2/settings-template.xml#L4

vs

https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources-filtered/settings.xml#L34

If we gave the mirror the id of "central" could we remove llr?

I shall take a test to see!

On 13 January 2017 at 10:34, Robert Scholte <rf...@apache.org> wrote:

> Just to be sure:
> MNG-3599 is about "webdav does not set http-proxy correctly"
> -llr (or --legacy-local-repository) introduced by MNG-5181 is about
> skipping some checks done when working with the default local repository.
> I don't see any relationship, in which case the test adjustment is fine
> for now.
> However, it would still be better if we didn't need this flag.
>
> Robert
>
>
> On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> Well now after several repeats still no sign of the failure when running
>> with -llr
>>
>> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>>
>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>>
>>> > Yes... oh and --legacy-local-repository fixed the tests:
>>>
>>> >
>>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599
>>> /4/testReport/
>>>
>>>
>>>
>>> Can you re-run the test on windows multiple times? The failure has not
>>>
>>> been reproducible so far. It succeeds a couple of times, then fails a
>>>
>>> couple of times, then succeeds again without anything having changed.
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> --
>>>
>> Sent from my phone
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: The failing MNG-3599 tests

Posted by Robert Scholte <rf...@apache.org>.
Just to be sure:
MNG-3599 is about "webdav does not set http-proxy correctly"
-llr (or --legacy-local-repository) introduced by MNG-5181 is about  
skipping some checks done when working with the default local repository.
I don't see any relationship, in which case the test adjustment is fine  
for now.
However, it would still be better if we didn't need this flag.

Robert

On Thu, 12 Jan 2017 01:32:36 +0100, Stephen Connolly  
<st...@gmail.com> wrote:

> Well now after several repeats still no sign of the failure when running
> with -llr
>
> On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>>
>> > Yes... oh and --legacy-local-repository fixed the tests:
>>
>> >
>> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/4/testReport/
>>
>>
>>
>> Can you re-run the test on windows multiple times? The failure has not
>>
>> been reproducible so far. It succeeds a couple of times, then fails a
>>
>> couple of times, then succeeds again without anything having changed.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
Well now after several repeats still no sign of the failure when running
with -llr

On Wed 11 Jan 2017 at 21:08, Christian Schulte <cs...@schulte.it> wrote:

> Am 01/11/17 um 17:53 schrieb Stephen Connolly:
>
> > Yes... oh and --legacy-local-repository fixed the tests:
>
> >
> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/4/testReport/
>
>
>
> Can you re-run the test on windows multiple times? The failure has not
>
> been reproducible so far. It succeeds a couple of times, then fails a
>
> couple of times, then succeeds again without anything having changed.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone

Re: The failing MNG-3599 tests

Posted by Christian Schulte <cs...@schulte.it>.
Am 01/11/17 um 17:53 schrieb Stephen Connolly:
> Yes... oh and --legacy-local-repository fixed the tests:
> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/4/testReport/

Can you re-run the test on windows multiple times? The failure has not
been reproducible so far. It succeeds a couple of times, then fails a
couple of times, then succeeds again without anything having changed.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
By yes I mean that each tes run starts all the integration tests from a
clean build but I do pre-populate the local repo with the webdav wagon:
https://github.com/apache/maven-integration-testing/blob/mng-3599/core-it-suite/src/test/resources/bootstrap/group-7/pom.xml#L46

The issue is that that wagon comes from a different repository URL and we
are storing the proxy URL that the artifact came from IIUC

On 11 January 2017 at 16:53, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Yes... oh and --legacy-local-repository fixed the tests:
> https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/4/testReport/
>
> On 11 January 2017 at 15:23, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> Are we starting from an empty local repo each time ?
>>
>> On Wed, Jan 11, 2017 at 3:00 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> > https://builds.apache.org/job/maven-jenkinsfile/job/mng-
>> > 3599/3/testReport/org.apache.maven.it/MavenITmng3599useHttpProxyForW
>> > ebDAVMk2Test/testitUseHttpProxyForWebDAV_4/
>> >
>> > So why is this consistently failing on windows?
>> >
>> > I think it is that we are running without --legacy-local-repository so I
>> > have kicked off another run to see but if this does let it pass then I
>> > think we have some interesting issue to digest
>> >
>> > On 11 January 2017 at 09:54, Stephen Connolly <
>> > stephen.alan.connolly@gmail.com> wrote:
>> >
>> > > After some analysis I think this is the Wagon upgrade to 2.10 in Maven
>> > > 3.3.9
>> > >
>> > > I have created a mng-3599 branch in maven-integration-tests with my
>> > > proposed fix (namely deactivate the old test from 3.3.9 onwards and
>> > > duplicate with a new test for 3.3.9 onwards
>> > >
>> > > I have committed a throw-away branch in maven-core called mng-3599
>> with
>> > > the Jenkinsfile pointing at the mng-3599 integration tests...
>> > >
>> > > Let's see if that fixes our test for us: https://builds.apache.org/
>> > > job/maven-jenkinsfile/job/mng-3599/
>> > >
>> >
>>
>>
>>
>> --
>> -----
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
>
>

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
Yes... oh and --legacy-local-repository fixed the tests:
https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/4/testReport/

On 11 January 2017 at 15:23, Arnaud Héritier <ah...@gmail.com> wrote:

> Are we starting from an empty local repo each time ?
>
> On Wed, Jan 11, 2017 at 3:00 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > https://builds.apache.org/job/maven-jenkinsfile/job/mng-
> > 3599/3/testReport/org.apache.maven.it/MavenITmng3599useHttpProxyForW
> > ebDAVMk2Test/testitUseHttpProxyForWebDAV_4/
> >
> > So why is this consistently failing on windows?
> >
> > I think it is that we are running without --legacy-local-repository so I
> > have kicked off another run to see but if this does let it pass then I
> > think we have some interesting issue to digest
> >
> > On 11 January 2017 at 09:54, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > After some analysis I think this is the Wagon upgrade to 2.10 in Maven
> > > 3.3.9
> > >
> > > I have created a mng-3599 branch in maven-integration-tests with my
> > > proposed fix (namely deactivate the old test from 3.3.9 onwards and
> > > duplicate with a new test for 3.3.9 onwards
> > >
> > > I have committed a throw-away branch in maven-core called mng-3599 with
> > > the Jenkinsfile pointing at the mng-3599 integration tests...
> > >
> > > Let's see if that fixes our test for us: https://builds.apache.org/
> > > job/maven-jenkinsfile/job/mng-3599/
> > >
> >
>
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: The failing MNG-3599 tests

Posted by Arnaud Héritier <ah...@gmail.com>.
Are we starting from an empty local repo each time ?

On Wed, Jan 11, 2017 at 3:00 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> https://builds.apache.org/job/maven-jenkinsfile/job/mng-
> 3599/3/testReport/org.apache.maven.it/MavenITmng3599useHttpProxyForW
> ebDAVMk2Test/testitUseHttpProxyForWebDAV_4/
>
> So why is this consistently failing on windows?
>
> I think it is that we are running without --legacy-local-repository so I
> have kicked off another run to see but if this does let it pass then I
> think we have some interesting issue to digest
>
> On 11 January 2017 at 09:54, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > After some analysis I think this is the Wagon upgrade to 2.10 in Maven
> > 3.3.9
> >
> > I have created a mng-3599 branch in maven-integration-tests with my
> > proposed fix (namely deactivate the old test from 3.3.9 onwards and
> > duplicate with a new test for 3.3.9 onwards
> >
> > I have committed a throw-away branch in maven-core called mng-3599 with
> > the Jenkinsfile pointing at the mng-3599 integration tests...
> >
> > Let's see if that fixes our test for us: https://builds.apache.org/
> > job/maven-jenkinsfile/job/mng-3599/
> >
>



-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: The failing MNG-3599 tests

Posted by Stephen Connolly <st...@gmail.com>.
https://builds.apache.org/job/maven-jenkinsfile/job/mng-3599/3/testReport/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVMk2Test/testitUseHttpProxyForWebDAV_4/

So why is this consistently failing on windows?

I think it is that we are running without --legacy-local-repository so I
have kicked off another run to see but if this does let it pass then I
think we have some interesting issue to digest

On 11 January 2017 at 09:54, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> After some analysis I think this is the Wagon upgrade to 2.10 in Maven
> 3.3.9
>
> I have created a mng-3599 branch in maven-integration-tests with my
> proposed fix (namely deactivate the old test from 3.3.9 onwards and
> duplicate with a new test for 3.3.9 onwards
>
> I have committed a throw-away branch in maven-core called mng-3599 with
> the Jenkinsfile pointing at the mng-3599 integration tests...
>
> Let's see if that fixes our test for us: https://builds.apache.org/
> job/maven-jenkinsfile/job/mng-3599/
>