Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Stephen Connolly]

I'll rephrase.

That test is currently passing on 3.3.9. Why?

If that testing passing on 3.3.9 because 3.3.9 was (badly) designed to work
that way? If yes then the test stays, change the range to [3.3.9,3.5.0) and
duplicate the test with the duplicate having the change and the range being
[3.5.0,)

If that test is passing on 3.3.9 because the test doesn't actually test
what it was intended to test, then it is fine to change that test

That the new version of the test will pass on 3.3.9 doesn't because of some
side effect is not a valid reason to change an existing test.

The test was run against 3.3.9 and 3.3.9 was released with that test
passing, unless you are absolutely certain that the test is a
false-positive or false-negative, we do not change the test (other than
range activation) rather we duplicate the test (second one being _mk2 or
something like that) and ensure that the duplicate has a different range
activation

HTH

On 10 January 2017 at 07:32, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So 5805 should be marked as only for [3.3.9] and then copy it for the
> rephrased version
>
> On Tue 10 Jan 2017 at 06:17, Anton Tanasenko 
> wrote:
>
>> Looks about right.
>>
>>
>>
>> Stephen, the change to MNG-5805 test as part of MNG-5958 was intentional,
>>
>> since I broke binary compat in the initial implementation of the feature.
>>
>> The changed test should also work with 3.3.9 which supported both 'phases'
>>
>> and 'lifecyclePhases' for the extended config, while after MNG-5958 one
>>
>> should only use 'lifecyclePhases' for that.
>>
>>
>>
>> 2017-01-10 6:13 GMT+02:00 Christian Schulte :
>>
>>
>>
>> > Hi,
>>
>> >
>>
>> > forgot to add those email addresses in the CC. Sending it again with the
>>
>> > authors in the CC.
>>
>> >
>>
>> >
>>
>> > Am 01/10/17 um 00:59 schrieb Christian Schulte:
>>
>> > > Am 01/10/17 um 00:40 schrieb Stephen Connolly:
>>
>> > >> It seems you are modifying an existing test:
>>
>> > >> https://github.com/apache/maven-integration-testing/blob/
>>
>> > 8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/
>>
>> > core-it-plugins/mng5805-extension/src/main/resources/
>>
>> > META-INF/plexus/components.xml
>>
>> > >>
>>
>> > >> Integration tests should be append-only (with rare exceptions)
>>
>> > >>
>>
>> > >> If the resource needs to be changed then mark the test with an upper
>>
>> > range
>>
>> > >> limit of ,3.5.0) and create the new test with a range limit of
>> [3.5.0,
>>
>> > >>
>>
>> > >> Changing existing tests is bad and was one of the reasons why we had
>> to
>>
>> > >> reset
>>
>> > >>
>>
>> > >> -1 on the current formulation of this change.
>>
>> > >
>>
>> > > I am only the committer. I'll try to bring the authors of the commits
>>
>> > > into the discussion.
>>
>> > >
>>
>> > > Issue: .
>>
>> > >
>>
>> > > Commit in the core:
>>
>> > > >
>> > 71ada08978c78d3b1416f0cf4f63942dddb171d9>
>>
>> > >
>>
>> > > authorStuart McCulloch 
>>
>> > >   Wed, 6 Jan 2016 12:23:06 +0100 (11:23 +)
>>
>> > >
>>
>> > > Commit to the ITs:
>>
>> > > >
>> > integration-testing.git;a=commit;h=8852538208e508fdc7b58d6332ca68
>>
>> > 3bfc0c9373>
>>
>> > >
>>
>> > > authorAnton Tanasenko 
>>
>> > >   Thu, 7 Jan 2016 03:01:28 +0100 (04:01 +0200)
>>
>> > >
>>
>> > > Issue introducing the IT which needs to be changed:
>>
>> > > 
>>
>> > >
>>
>> > > Commits to the core:
>>
>> > > >
>> > 3677220f6e499e97f2b47b0593bc394b689d14d6>
>>
>> > >
>>
>> > > authorAnton Tanasenko 
>>
>> > >   Sun, 19 Jul 2015 22:01:50 +0100 (00:01 +0300)
>>
>> > >
>>
>> > > >
>> > 9f7971dadbec8882b4c119345494b620d3a1f897>
>>
>> > >
>>
>> > > authorAnton Tanasenko 
>>
>> > >   Sat, 1 Aug 2015 15:02:52 +0100 (17:02 +0300)
>>
>> > >
>>
>> > > Commits to the ITs due to this:
>>
>> > > >
>> > integration-testing.git;a=commit;h=63656ffd5cd9c5287715336a5f91ba
>>
>> > f27c8360f1>
>>
>> > >
>>
>> > > authorAnton Tanasenko 
>>
>> > >   Sun, 19 Apr 2015 22:50:37 +0100 (00:50 +0300)
>>
>> > >
>>
>> > > >
>> > integration-testing.git;a=commit;h=ef7b0d378305ab62aa7b3824b80858
>>
>> > 8e5cb1a11e>
>>
>> > >
>>
>> > > authorAnton Tanasenko 
>>
>> > >   Mon, 27 Apr 2015 22:58:32 +0100 (00:58 +0300)
>>
>> > >
>>
>> > > The author of the IT being changed appears to be the same author who
>>
>> > > contributed the initial 

Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Stephen Connolly]

So 5805 should be marked as only for [3.3.9] and then copy it for the
rephrased version

On Tue 10 Jan 2017 at 06:17, Anton Tanasenko 
wrote:

> Looks about right.
>
>
>
> Stephen, the change to MNG-5805 test as part of MNG-5958 was intentional,
>
> since I broke binary compat in the initial implementation of the feature.
>
> The changed test should also work with 3.3.9 which supported both 'phases'
>
> and 'lifecyclePhases' for the extended config, while after MNG-5958 one
>
> should only use 'lifecyclePhases' for that.
>
>
>
> 2017-01-10 6:13 GMT+02:00 Christian Schulte :
>
>
>
> > Hi,
>
> >
>
> > forgot to add those email addresses in the CC. Sending it again with the
>
> > authors in the CC.
>
> >
>
> >
>
> > Am 01/10/17 um 00:59 schrieb Christian Schulte:
>
> > > Am 01/10/17 um 00:40 schrieb Stephen Connolly:
>
> > >> It seems you are modifying an existing test:
>
> > >> https://github.com/apache/maven-integration-testing/blob/
>
> > 8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/
>
> > core-it-plugins/mng5805-extension/src/main/resources/
>
> > META-INF/plexus/components.xml
>
> > >>
>
> > >> Integration tests should be append-only (with rare exceptions)
>
> > >>
>
> > >> If the resource needs to be changed then mark the test with an upper
>
> > range
>
> > >> limit of ,3.5.0) and create the new test with a range limit of [3.5.0,
>
> > >>
>
> > >> Changing existing tests is bad and was one of the reasons why we had
> to
>
> > >> reset
>
> > >>
>
> > >> -1 on the current formulation of this change.
>
> > >
>
> > > I am only the committer. I'll try to bring the authors of the commits
>
> > > into the discussion.
>
> > >
>
> > > Issue: .
>
> > >
>
> > > Commit in the core:
>
> > > 
> > 71ada08978c78d3b1416f0cf4f63942dddb171d9>
>
> > >
>
> > > authorStuart McCulloch 
>
> > >   Wed, 6 Jan 2016 12:23:06 +0100 (11:23 +)
>
> > >
>
> > > Commit to the ITs:
>
> > > 
> > integration-testing.git;a=commit;h=8852538208e508fdc7b58d6332ca68
>
> > 3bfc0c9373>
>
> > >
>
> > > authorAnton Tanasenko 
>
> > >   Thu, 7 Jan 2016 03:01:28 +0100 (04:01 +0200)
>
> > >
>
> > > Issue introducing the IT which needs to be changed:
>
> > > 
>
> > >
>
> > > Commits to the core:
>
> > > 
> > 3677220f6e499e97f2b47b0593bc394b689d14d6>
>
> > >
>
> > > authorAnton Tanasenko 
>
> > >   Sun, 19 Jul 2015 22:01:50 +0100 (00:01 +0300)
>
> > >
>
> > > 
> > 9f7971dadbec8882b4c119345494b620d3a1f897>
>
> > >
>
> > > authorAnton Tanasenko 
>
> > >   Sat, 1 Aug 2015 15:02:52 +0100 (17:02 +0300)
>
> > >
>
> > > Commits to the ITs due to this:
>
> > > 
> > integration-testing.git;a=commit;h=63656ffd5cd9c5287715336a5f91ba
>
> > f27c8360f1>
>
> > >
>
> > > authorAnton Tanasenko 
>
> > >   Sun, 19 Apr 2015 22:50:37 +0100 (00:50 +0300)
>
> > >
>
> > > 
> > integration-testing.git;a=commit;h=ef7b0d378305ab62aa7b3824b80858
>
> > 8e5cb1a11e>
>
> > >
>
> > > authorAnton Tanasenko 
>
> > >   Mon, 27 Apr 2015 22:58:32 +0100 (00:58 +0300)
>
> > >
>
> > > The author of the IT being changed appears to be the same author who
>
> > > contributed the initial version.
>
> > >
>
> > > +1 from me (committer) for the change.
>
> > >
>
> > > Regards,
>
> > >
>
> >
>
> >
>
>
>
>
>
> --
>
> Regards,
>
> Anton.
>
> --
Sent from my phone

Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Anton Tanasenko]

Looks about right.

Stephen, the change to MNG-5805 test as part of MNG-5958 was intentional,
since I broke binary compat in the initial implementation of the feature.
The changed test should also work with 3.3.9 which supported both 'phases'
and 'lifecyclePhases' for the extended config, while after MNG-5958 one
should only use 'lifecyclePhases' for that.

2017-01-10 6:13 GMT+02:00 Christian Schulte :

> Hi,
>
> forgot to add those email addresses in the CC. Sending it again with the
> authors in the CC.
>
>
> Am 01/10/17 um 00:59 schrieb Christian Schulte:
> > Am 01/10/17 um 00:40 schrieb Stephen Connolly:
> >> It seems you are modifying an existing test:
> >> https://github.com/apache/maven-integration-testing/blob/
> 8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/
> core-it-plugins/mng5805-extension/src/main/resources/
> META-INF/plexus/components.xml
> >>
> >> Integration tests should be append-only (with rare exceptions)
> >>
> >> If the resource needs to be changed then mark the test with an upper
> range
> >> limit of ,3.5.0) and create the new test with a range limit of [3.5.0,
> >>
> >> Changing existing tests is bad and was one of the reasons why we had to
> >> reset
> >>
> >> -1 on the current formulation of this change.
> >
> > I am only the committer. I'll try to bring the authors of the commits
> > into the discussion.
> >
> > Issue: .
> >
> > Commit in the core:
> >  71ada08978c78d3b1416f0cf4f63942dddb171d9>
> >
> > authorStuart McCulloch 
> >   Wed, 6 Jan 2016 12:23:06 +0100 (11:23 +)
> >
> > Commit to the ITs:
> >  integration-testing.git;a=commit;h=8852538208e508fdc7b58d6332ca68
> 3bfc0c9373>
> >
> > authorAnton Tanasenko 
> >   Thu, 7 Jan 2016 03:01:28 +0100 (04:01 +0200)
> >
> > Issue introducing the IT which needs to be changed:
> > 
> >
> > Commits to the core:
> >  3677220f6e499e97f2b47b0593bc394b689d14d6>
> >
> > authorAnton Tanasenko 
> >   Sun, 19 Jul 2015 22:01:50 +0100 (00:01 +0300)
> >
> >  9f7971dadbec8882b4c119345494b620d3a1f897>
> >
> > authorAnton Tanasenko 
> >   Sat, 1 Aug 2015 15:02:52 +0100 (17:02 +0300)
> >
> > Commits to the ITs due to this:
> >  integration-testing.git;a=commit;h=63656ffd5cd9c5287715336a5f91ba
> f27c8360f1>
> >
> > authorAnton Tanasenko 
> >   Sun, 19 Apr 2015 22:50:37 +0100 (00:50 +0300)
> >
> >  integration-testing.git;a=commit;h=ef7b0d378305ab62aa7b3824b80858
> 8e5cb1a11e>
> >
> > authorAnton Tanasenko 
> >   Mon, 27 Apr 2015 22:58:32 +0100 (00:58 +0300)
> >
> > The author of the IT being changed appears to be the same author who
> > contributed the initial version.
> >
> > +1 from me (committer) for the change.
> >
> > Regards,
> >
>
>


-- 
Regards,
Anton.

Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Christian Schulte]

Hi,

forgot to add those email addresses in the CC. Sending it again with the
authors in the CC.


Am 01/10/17 um 00:59 schrieb Christian Schulte:
> Am 01/10/17 um 00:40 schrieb Stephen Connolly:
>> It seems you are modifying an existing test:
>> https://github.com/apache/maven-integration-testing/blob/8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/core-it-plugins/mng5805-extension/src/main/resources/META-INF/plexus/components.xml
>>
>> Integration tests should be append-only (with rare exceptions)
>>
>> If the resource needs to be changed then mark the test with an upper range
>> limit of ,3.5.0) and create the new test with a range limit of [3.5.0,
>>
>> Changing existing tests is bad and was one of the reasons why we had to
>> reset
>>
>> -1 on the current formulation of this change.
> 
> I am only the committer. I'll try to bring the authors of the commits
> into the discussion.
> 
> Issue: .
> 
> Commit in the core:
> 
> 
> authorStuart McCulloch 
>   Wed, 6 Jan 2016 12:23:06 +0100 (11:23 +)
> 
> Commit to the ITs:
> 
> 
> authorAnton Tanasenko    
>   Thu, 7 Jan 2016 03:01:28 +0100 (04:01 +0200)
> 
> Issue introducing the IT which needs to be changed:
> 
> 
> Commits to the core:
> 
> 
> authorAnton Tanasenko    
>   Sun, 19 Jul 2015 22:01:50 +0100 (00:01 +0300)
> 
> 
> 
> authorAnton Tanasenko    
>   Sat, 1 Aug 2015 15:02:52 +0100 (17:02 +0300)
> 
> Commits to the ITs due to this:
> 
> 
> authorAnton Tanasenko    
>   Sun, 19 Apr 2015 22:50:37 +0100 (00:50 +0300)
> 
> 
> 
> authorAnton Tanasenko    
>   Mon, 27 Apr 2015 22:58:32 +0100 (00:58 +0300)
> 
> The author of the IT being changed appears to be the same author who
> contributed the initial version.
> 
> +1 from me (committer) for the change.
> 
> Regards,
> 


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

Re: [DISCUSS] Stop allowing forced pushes to GIT repositories.

[Christian Schulte]

Am 01/09/17 um 12:23 schrieb Stephen Connolly:
> And INFRA have applied the protections to the master branches of all our
> Git repos

Thanks.


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

Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Christian Schulte]

Am 01/10/17 um 00:40 schrieb Stephen Connolly:
> It seems you are modifying an existing test:
> https://github.com/apache/maven-integration-testing/blob/8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/core-it-plugins/mng5805-extension/src/main/resources/META-INF/plexus/components.xml
> 
> Integration tests should be append-only (with rare exceptions)
> 
> If the resource needs to be changed then mark the test with an upper range
> limit of ,3.5.0) and create the new test with a range limit of [3.5.0,
> 
> Changing existing tests is bad and was one of the reasons why we had to
> reset
> 
> -1 on the current formulation of this change.

I am only the committer. I'll try to bring the authors of the commits
into the discussion.

Issue: .

Commit in the core:


author  Stuart McCulloch 
Wed, 6 Jan 2016 12:23:06 +0100 (11:23 +)

Commit to the ITs:


author  Anton Tanasenko    
Thu, 7 Jan 2016 03:01:28 +0100 (04:01 +0200)

Issue introducing the IT which needs to be changed:


Commits to the core:


author  Anton Tanasenko    
Sun, 19 Jul 2015 22:01:50 +0100 (00:01 +0300)



author  Anton Tanasenko    
Sat, 1 Aug 2015 15:02:52 +0100 (17:02 +0300)

Commits to the ITs due to this:


author  Anton Tanasenko    
Sun, 19 Apr 2015 22:50:37 +0100 (00:50 +0300)



author  Anton Tanasenko    
Mon, 27 Apr 2015 22:58:32 +0100 (00:58 +0300)

The author of the IT being changed appears to be the same author who
contributed the initial version.

+1 from me (committer) for the change.

Regards,
-- 
Christian


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

Re: [IT MNG-5958]: Please review integration test for MNG-5958

[Stephen Connolly]

It seems you are modifying an existing test:
https://github.com/apache/maven-integration-testing/blob/8852538208e508fdc7b58d6332ca683bfc0c9373/core-it-support/core-it-plugins/mng5805-extension/src/main/resources/META-INF/plexus/components.xml

Integration tests should be append-only (with rare exceptions)

If the resource needs to be changed then mark the test with an upper range
limit of ,3.5.0) and create the new test with a range limit of [3.5.0,

Changing existing tests is bad and was one of the reasons why we had to
reset

-1 on the current formulation of this change.
On Mon 9 Jan 2017 at 23:21, Christian Schulte  wrote:

> Commit to review is here:
>
>
>
> <
> https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=8852538208e508fdc7b58d6332ca683bfc0c9373
> >
>
>
>
> If no one objects until Friday, 13th, 2017, I'll merge it to master.
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

[IT MNG-5958]: Please review integration test for MNG-5958

[Christian Schulte]

Commit to review is here:



If no one objects until Friday, 13th, 2017, I'll merge it to master.

Regards,
-- 
Christian

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

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

Yes. And the branch job will be deleted automatically after you delete the
branch (we can set an orphaned item strategy if we want to keep them around
for a while)

On Mon 9 Jan 2017 at 22:44, Christian Schulte  wrote:

> Am 01/09/17 um 23:36 schrieb Stephen Connolly:
>
> > Yes, every branch that has the Jenkinsfile will automatically get its own
>
> > branch job build within 15 minutes of being pushed.
>
> >
>
> > (It would be faster - i.e. 5s after the push - but until I don't want to
>
> > pester infra to upgrade Jenkins until I have got some stability in the
>
> > branch-api 2.0.x series)
>
> >
>
> > There is also ever cooler when I get
>
> > https://github.com/jenkinsci/workflow-multibranch-plugin/pull/46 merged
> and
>
> > released...
>
> >
>
> > The Jenkinsfile will then use *the matching integration test branch if it
>
> > exists* and fall back to master if missing... so you will be able to even
>
> > get the results of the new integration tests before merging... but
> that's a
>
> > few weeks away I suspect
>
>
>
> Very cool. So I can prepare a local branch per issue, push that, wait
>
> for Jenkins to build it and if everything went well, pick the commit
>
> into master and remove the branch afterwards?
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Infra question: One commit -> multiple issues.

[Christian Schulte]

Am 01/09/17 um 23:36 schrieb Stephen Connolly:
> Yes, every branch that has the Jenkinsfile will automatically get its own
> branch job build within 15 minutes of being pushed.
> 
> (It would be faster - i.e. 5s after the push - but until I don't want to
> pester infra to upgrade Jenkins until I have got some stability in the
> branch-api 2.0.x series)
> 
> There is also ever cooler when I get
> https://github.com/jenkinsci/workflow-multibranch-plugin/pull/46 merged and
> released...
> 
> The Jenkinsfile will then use *the matching integration test branch if it
> exists* and fall back to master if missing... so you will be able to even
> get the results of the new integration tests before merging... but that's a
> few weeks away I suspect

Very cool. So I can prepare a local branch per issue, push that, wait
for Jenkins to build it and if everything went well, pick the commit
into master and remove the branch afterwards?


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

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

Yes, every branch that has the Jenkinsfile will automatically get its own
branch job build within 15 minutes of being pushed.

(It would be faster - i.e. 5s after the push - but until I don't want to
pester infra to upgrade Jenkins until I have got some stability in the
branch-api 2.0.x series)

There is also ever cooler when I get
https://github.com/jenkinsci/workflow-multibranch-plugin/pull/46 merged and
released...

The Jenkinsfile will then use *the matching integration test branch if it
exists* and fall back to master if missing... so you will be able to even
get the results of the new integration tests before merging... but that's a
few weeks away I suspect

On Mon 9 Jan 2017 at 22:27, Christian Schulte  wrote:

> Am 01/09/17 um 22:44 schrieb Stephen Connolly:
>
> > Can we stage this logical set of changes on the same branch before
> merging
>
> > to master (so we know we have a clean test run on the
>
> > https://builds.apache.org/job/maven-jenkinsfile/ branch build)
>
>
>
> What's this Jenkinsfile about? Does it mean whenever someone creates a
>
> branch from master with that Jenkinsfile and pushes it, Jenkins will
>
> pick up that branch and perform a build of it and run the ITs against
>
> it? That would be mega cool. Instead of cherry picking the commits
>
> sequentially into master, there better be some intermediate branch with
>
> all those commits which can then be merged into master in one go.
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Infra question: One commit -> multiple issues.

[Christian Schulte]

Am 01/09/17 um 22:44 schrieb Stephen Connolly:
> Can we stage this logical set of changes on the same branch before merging
> to master (so we know we have a clean test run on the
> https://builds.apache.org/job/maven-jenkinsfile/ branch build)

What's this Jenkinsfile about? Does it mean whenever someone creates a
branch from master with that Jenkinsfile and pushes it, Jenkins will
pick up that branch and perform a build of it and run the ITs against
it? That would be mega cool. Instead of cherry picking the commits
sequentially into master, there better be some intermediate branch with
all those commits which can then be merged into master in one go.


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

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

Can we stage this logical set of changes on the same branch before merging
to master (so we know we have a clean test run on the
https://builds.apache.org/job/maven-jenkinsfile/ branch build)

On Mon 9 Jan 2017 at 21:41, Christian Schulte  wrote:

> Am 01/09/17 um 21:03 schrieb Michael Osipov:
>
> > Am 2017-01-09 um 19:58 schrieb Stephen Connolly:
>
> >> If the commit mentions all the issues, e.g. [MNG-1235, MNG-4568] there
>
> >> should be reasonable tracking... but if you feel more confident with one
>
> >> issue per commit I see no issue with that either
>
> >
>
> > Personally, yes. I have seen comments from users on issues where they
>
> > refer to a specific commit. Luckily, those were one issue per commit.
>
> > Made it pretty easy to analyze. I'd like to keep it that way.
>
> >
>
>
>
> I unassigned myself from those issues. You need to coordinate with Tibor
>
> to get things committed in order. It's multiple issues but the same
>
> files to change. You'll get conflicts if both of you start committing
>
> now without coordinating the changes.
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Infra question: One commit -> multiple issues.

[Christian Schulte]

Am 01/09/17 um 21:03 schrieb Michael Osipov:
> Am 2017-01-09 um 19:58 schrieb Stephen Connolly:
>> If the commit mentions all the issues, e.g. [MNG-1235, MNG-4568] there
>> should be reasonable tracking... but if you feel more confident with one
>> issue per commit I see no issue with that either
> 
> Personally, yes. I have seen comments from users on issues where they 
> refer to a specific commit. Luckily, those were one issue per commit. 
> Made it pretty easy to analyze. I'd like to keep it that way.
> 

I unassigned myself from those issues. You need to coordinate with Tibor
to get things committed in order. It's multiple issues but the same
files to change. You'll get conflicts if both of you start committing
now without coordinating the changes.

Regards,
-- 
Christian


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

[GitHub] maven-wagon pull request #32: [WAGON-485] ScpWagon file size Integer to Long

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon issue #32: [WAGON-485] ScpWagon file size Integer to Long

[stephenc]

Github user stephenc commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
LGTM


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon issue #32: [WAGON-485] ScpWagon file size Integer to Long

[oassuncao]

Github user oassuncao commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
I squash the commits.

Thanks


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon issue #32: [WAGON-485] ScpWagon file size Integer to Long

[oassuncao]

Github user oassuncao commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
Changed the code to use `Long.parseLong`


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon issue #32: [WAGON-485] ScpWagon file size Integer to Long

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
Please squash them.


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon pull request #32: [WAGON-485] ScpWagon file size Integer to Long

[michael-o]

Github user michael-o commented on a diff in the pull request:

https://github.com/apache/maven-wagon/pull/32#discussion_r95234762
  
--- Diff: 
wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/ScpWagon.java
 ---
@@ -297,7 +297,7 @@ public void fillInputData( InputData inputData )
 throw new IOException( "Invalid transfer header: " + line 
);
 }
 
-int filesize = Integer.valueOf( line.substring( 5, index ) 
).intValue();
+long filesize = Long.valueOf( line.substring( 5, index ) );
--- End diff --

Good point. Waiting for this to be integrated and I will ran all tests 
against the patch.


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Infra question: One commit -> multiple issues.

[Michael Osipov]

Am 2017-01-09 um 19:58 schrieb Stephen Connolly:

If the commit mentions all the issues, e.g. [MNG-1235, MNG-4568] there
should be reasonable tracking... but if you feel more confident with one
issue per commit I see no issue with that either


Personally, yes. I have seen comments from users on issues where they 
refer to a specific commit. Luckily, those were one issue per commit. 
Made it pretty easy to analyze. I'd like to keep it that way.


Michael


On Mon 9 Jan 2017 at 18:51, Michael Osipov  wrote:


Am 2017-01-09 um 16:13 schrieb Christian Schulte:


Hi,







there have been various issues in JIRA regarding the launcher scripts.



Is it possible to squash all those commits into one and then mention all



JIRA issues in the commit message so that the commit is added to each



JIRA issue? Last time I did this I think Jenkins was able to add



comments to all issues involved. I would just copy the launchers from



the pre-reset-master branch to master and just mention all issues in the



commit.




What about traceability for users? They would not be able to find the

distinct change for a ticket anymore. It makes it hard to trace a

regression.



Michael





-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For additional commands, e-mail: dev-h...@maven.apache.org



--

Sent from my phone




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

[GitHub] maven-wagon pull request #32: [WAGON-485] ScpWagon file size Integer to Long

[Tunaki]

Github user Tunaki commented on a diff in the pull request:

https://github.com/apache/maven-wagon/pull/32#discussion_r95232415
  
--- Diff: 
wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/ScpWagon.java
 ---
@@ -297,7 +297,7 @@ public void fillInputData( InputData inputData )
 throw new IOException( "Invalid transfer header: " + line 
);
 }
 
-int filesize = Integer.valueOf( line.substring( 5, index ) 
).intValue();
+long filesize = Long.valueOf( line.substring( 5, index ) );
--- End diff --

Small note, `Long.parseLong` is better here as it wouldn't involve an 
unboxing conversion.


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Maven 3.4.0 dropped

[Stephen Connolly]

If you are a user who tried one of the 3.4.0-SNAPSHOT builds...

and then you see *no* 3.4.x at all but instead a 3.5.0

Or you see a 3.4.0

Which is more likely to make you go and read the release notes which will
explain what happened?

The considered option of those I asked were in favour of 3.5.0

On Mon 9 Jan 2017 at 17:22, Gary Gregory  wrote:

> Note that by going from 3.3.9 to 3.5.0, this will add to the confusion from
>
> the user's POV.
>
>
>
> Gary
>
>
>
> On Mon, Jan 9, 2017 at 1:45 AM, Stephen Connolly 
>
> wrote:
>
>
>
> > After some discussion and debate, the Maven developers have agreed [1] to
>
> > replan the next release of Maven.
>
> >
>
> > The original plans for Maven 3.4.0 were that it should consist of
>
> > effectively a no-op drop in replacement of Eclipse's Aether project
> (which
>
> > has been retired at the Eclipse Foundation) for the migrated code now
> known
>
> > as Apache's Maven Resolver. Additionally the plans called for some other
>
> > orthogonal changes around logging colourization and some launcher script
>
> > bug fixes.
>
> >
>
> > Due to some misunderstanding, there were quite a number of other changes
>
> > introduced which could be seen as modifying how dependencies and
> classpaths
>
> > get built. While we want to get these changes released as bug fixes, it
> is
>
> > also important to us to provide a clear progression of development. Some
> of
>
> > the bugs we want to fix require changes to the resolver code and the
>
> > developers feel it is important to mark the baseline of the migrated code
>
> > such that it should be a drop-in replacement for 3.3.9.
>
> >
>
> > In that regard we have reset the master branches of the following GIT
>
> > repositories to the point in time that corresponds to the 3.3.9 release:
>
> >
>
> > * git://git.apache.org/maven.git was reset to
>
> > bce33aa2662a51d18cb00347cf2fb174dc195fb1
>
> >
>
> > * git://git.apache.org/maven-integration-testing.git was reset to
>
> > f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> >
>
> > * git://git.apache.org/maven-resolver.git was reset to
>
> > b74f7a1e8837875b4780199f644119f55d22465d
>
> >
>
> > If you have clones of any of these repositories you will need to update
>
> > them as the master branch has been force-pushed.
>
> >
>
> > As there have already been issues closed as fixed in 3.4.0 and a number
> of
>
> > 3.4.0-SNAPSHOT releases were distributed for user feedback, it has been
>
> > decided to burn the 3.4.0 version number as a signal of the reset. The
> next
>
> > release of Maven will thus be 3.5.0
>
> >
>
> > We have a (mostly) agreed plan for the content of the 3.5.0 release [2]
>
> > (there are still some issues being decided on)
>
> >
>
> > As all the content of 3.5.0 has already been developed on the old master
>
> > branches (which have been retained as the pre-reset-master branches) it
>
> > should be relatively easy to pull each of the agreed changes and merge
>
> > them. For this reason we hope to be able to cut a release candidate of
>
> > 3.5.0 relatively quickly.
>
> >
>
> > The next step will be agreeing the content of next release (which we hope
>
> > to have follow 3.5.0 after 6-8 weeks and will either be called 3.5.1 or
>
> > 3.6.0 depending on the agreed content).
>
> >
>
> > The drive is to get almost all the content that was in the
> pre-reset-master
>
> > released, but in a version history that makes it easier for users to
>
> > understand the impact and makes it easier for developers to identify the
>
> > potential impact of the changes.
>
> >
>
> > - Stephen
>
> >
>
> > (On behalf of the Apache Maven Project)
>
> >
>
> > [1]:
>
> > https://mail-archives.apache.org/mod_mbox/maven-dev/201701.
>
> > mbox/%3CCA%2BnPnMx-e7kGYy3Hp87v8hLGdhp1q%3DtKLx_
>
> > 6QuZ4kGUqHEBGcw%40mail.gmail.com%3E
>
> >
>
> > [2]: https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017
>
> >
>
>
>
>
>
>
>
> --
>
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>
> Java Persistence with Hibernate, Second Edition
>
> <
> https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
> >
>
>
>
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
>
> JUnit in Action, Second Edition
>
> <
> https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>
>
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
>
> Spring Batch in Action
>
> <
> https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> >
>
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
>
> Blog: http://garygregory.wordpress.com
>
> Home: http://garygregory.com/
>
> Tweet! http://twitter.com/GaryGregory
>
> --
Sent 

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

If the commit mentions all the issues, e.g. [MNG-1235, MNG-4568] there
should be reasonable tracking... but if you feel more confident with one
issue per commit I see no issue with that either

On Mon 9 Jan 2017 at 18:51, Michael Osipov  wrote:

> Am 2017-01-09 um 16:13 schrieb Christian Schulte:
>
> > Hi,
>
> >
>
> > there have been various issues in JIRA regarding the launcher scripts.
>
> > Is it possible to squash all those commits into one and then mention all
>
> > JIRA issues in the commit message so that the commit is added to each
>
> > JIRA issue? Last time I did this I think Jenkins was able to add
>
> > comments to all issues involved. I would just copy the launchers from
>
> > the pre-reset-master branch to master and just mention all issues in the
>
> > commit.
>
>
>
> What about traceability for users? They would not be able to find the
>
> distinct change for a ticket anymore. It makes it hard to trace a
>
> regression.
>
>
>
> Michael
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

[GitHub] maven-wagon issue #32: ScpWagon file size Integer to Long

[oassuncao]

Github user oassuncao commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
If you check the `resource.setContentLength` this method receive a long 
value as a parameter. In the `ScpWagon` convert the integer to long (java 
cast). 

I only parse the value to Long, because if you have large file you will 
receive a error. My file has 3.8 GB in bytes is 3865470566. It is more than the 
capability of Integer Java


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Infra question: One commit -> multiple issues.

[Michael Osipov]

Am 2017-01-09 um 16:13 schrieb Christian Schulte:

Hi,

there have been various issues in JIRA regarding the launcher scripts.
Is it possible to squash all those commits into one and then mention all
JIRA issues in the commit message so that the commit is added to each
JIRA issue? Last time I did this I think Jenkins was able to add
comments to all issues involved. I would just copy the launchers from
the pre-reset-master branch to master and just mention all issues in the
commit.


What about traceability for users? They would not be able to find the 
distinct change for a ticket anymore. It makes it hard to trace a 
regression.


Michael


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

[GitHub] maven-wagon issue #32: ScpWagon file size Integer to Long

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven-wagon/pull/32
  
Is the value in bytes? If though, this truly can fail with intergers. 
Please open a JIRA issue for that.


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Maven 3.4.0 dropped

[Gary Gregory]

Note that by going from 3.3.9 to 3.5.0, this will add to the confusion from
the user's POV.

Gary

On Mon, Jan 9, 2017 at 1:45 AM, Stephen Connolly 
wrote:

> After some discussion and debate, the Maven developers have agreed [1] to
> replan the next release of Maven.
>
> The original plans for Maven 3.4.0 were that it should consist of
> effectively a no-op drop in replacement of Eclipse's Aether project (which
> has been retired at the Eclipse Foundation) for the migrated code now known
> as Apache's Maven Resolver. Additionally the plans called for some other
> orthogonal changes around logging colourization and some launcher script
> bug fixes.
>
> Due to some misunderstanding, there were quite a number of other changes
> introduced which could be seen as modifying how dependencies and classpaths
> get built. While we want to get these changes released as bug fixes, it is
> also important to us to provide a clear progression of development. Some of
> the bugs we want to fix require changes to the resolver code and the
> developers feel it is important to mark the baseline of the migrated code
> such that it should be a drop-in replacement for 3.3.9.
>
> In that regard we have reset the master branches of the following GIT
> repositories to the point in time that corresponds to the 3.3.9 release:
>
> * git://git.apache.org/maven.git was reset to
> bce33aa2662a51d18cb00347cf2fb174dc195fb1
>
> * git://git.apache.org/maven-integration-testing.git was reset to
> f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> * git://git.apache.org/maven-resolver.git was reset to
> b74f7a1e8837875b4780199f644119f55d22465d
>
> If you have clones of any of these repositories you will need to update
> them as the master branch has been force-pushed.
>
> As there have already been issues closed as fixed in 3.4.0 and a number of
> 3.4.0-SNAPSHOT releases were distributed for user feedback, it has been
> decided to burn the 3.4.0 version number as a signal of the reset. The next
> release of Maven will thus be 3.5.0
>
> We have a (mostly) agreed plan for the content of the 3.5.0 release [2]
> (there are still some issues being decided on)
>
> As all the content of 3.5.0 has already been developed on the old master
> branches (which have been retained as the pre-reset-master branches) it
> should be relatively easy to pull each of the agreed changes and merge
> them. For this reason we hope to be able to cut a release candidate of
> 3.5.0 relatively quickly.
>
> The next step will be agreeing the content of next release (which we hope
> to have follow 3.5.0 after 6-8 weeks and will either be called 3.5.1 or
> 3.6.0 depending on the agreed content).
>
> The drive is to get almost all the content that was in the pre-reset-master
> released, but in a version history that makes it easier for users to
> understand the impact and makes it easier for developers to identify the
> potential impact of the changes.
>
> - Stephen
>
> (On behalf of the Apache Maven Project)
>
> [1]:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201701.
> mbox/%3CCA%2BnPnMx-e7kGYy3Hp87v8hLGdhp1q%3DtKLx_
> 6QuZ4kGUqHEBGcw%40mail.gmail.com%3E
>
> [2]: https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[GitHub] maven-site pull request #6: Enumerate inherited POM elements more thoroughly

[ctrueden]

Github user ctrueden closed the pull request at:

https://github.com/apache/maven-site/pull/6


---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

I suggest one of you creates a branch and you flatten each of your
sequential commits into that branch one at a time. The person to create the
branch should be the first commit and then proceed in order.

Or if you all agree then one of you can just create a branch with the final
end game committing with "Submitted by: .., .. and ..."

Entirely up to the three of you to agree what you want to do and what is
acceptable to you

On 9 January 2017 at 15:29, Christian Schulte  wrote:

> Am 01/09/17 um 16:13 schrieb Christian Schulte:
> > Hi,
> >
> > there have been various issues in JIRA regarding the launcher scripts.
> > Is it possible to squash all those commits into one and then mention all
> > JIRA issues in the commit message so that the commit is added to each
> > JIRA issue? Last time I did this I think Jenkins was able to add
> > comments to all issues involved. I would just copy the launchers from
> > the pre-reset-master branch to master and just mention all issues in the
> > commit.
> >
> > Regards,
> >
>
> Put another way. There are multiple issues in JIRA all dealing with the
> launcher scripts assigned to three different persons. Michael Osipov,
> Tibor Digana and me. Who wants to work on that? That should be only one
> person. Just assign yourself in JIRA then:
>
> MNG-5815
> MNG-5889
> MNG-5962
> MNG-5963
> MNG-6001
> MNG-6003
>
> I just unassigned me from the one issue I was assigned to. One note:
> Last commit to the Windows launcher is from me. Whatever gets committed,
> make sure to run the 'maven-assembly-plugin' ITs on Windows from inside
> a directory containing spaces and and ampersand character like:
>
> mkdir "directory with spaces and a & special char"
> cd "directory with spaces and a & special char"
> svn checkout
> https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin
> cd maven-assemby-plugin
> mvn -Prun-its verify
>
> You'll need to use the trunk of that plugin because it relies on a
> invoker plugin snapshot. That needs to pass on Linux and Windows.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Infra question: One commit -> multiple issues.

[Christian Schulte]

Am 01/09/17 um 16:13 schrieb Christian Schulte:
> Hi,
> 
> there have been various issues in JIRA regarding the launcher scripts.
> Is it possible to squash all those commits into one and then mention all
> JIRA issues in the commit message so that the commit is added to each
> JIRA issue? Last time I did this I think Jenkins was able to add
> comments to all issues involved. I would just copy the launchers from
> the pre-reset-master branch to master and just mention all issues in the
> commit.
> 
> Regards,
> 

Put another way. There are multiple issues in JIRA all dealing with the
launcher scripts assigned to three different persons. Michael Osipov,
Tibor Digana and me. Who wants to work on that? That should be only one
person. Just assign yourself in JIRA then:

MNG-5815
MNG-5889
MNG-5962
MNG-5963
MNG-6001
MNG-6003

I just unassigned me from the one issue I was assigned to. One note:
Last commit to the Windows launcher is from me. Whatever gets committed,
make sure to run the 'maven-assembly-plugin' ITs on Windows from inside
a directory containing spaces and and ampersand character like:

mkdir "directory with spaces and a & special char"
cd "directory with spaces and a & special char"
svn checkout
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin
cd maven-assemby-plugin
mvn -Prun-its verify

You'll need to use the trunk of that plugin because it relies on a
invoker plugin snapshot. That needs to pass on Linux and Windows.

Regards,
-- 
Christian


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

Re: Infra question: One commit -> multiple issues.

[Stephen Connolly]

If you did all the commits, then that is fine.

If you are effectively squashing the work of others, you'll probably need
to at least retain their commits with the authorship

On 9 January 2017 at 15:13, Christian Schulte  wrote:

> Hi,
>
> there have been various issues in JIRA regarding the launcher scripts.
> Is it possible to squash all those commits into one and then mention all
> JIRA issues in the commit message so that the commit is added to each
> JIRA issue? Last time I did this I think Jenkins was able to add
> comments to all issues involved. I would just copy the launchers from
> the pre-reset-master branch to master and just mention all issues in the
> commit.
>
> Regards,
> --
> Christian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Infra question: One commit -> multiple issues.

[Christian Schulte]

Hi,

there have been various issues in JIRA regarding the launcher scripts.
Is it possible to squash all those commits into one and then mention all
JIRA issues in the commit message so that the commit is added to each
JIRA issue? Last time I did this I think Jenkins was able to add
comments to all issues involved. I would just copy the launchers from
the pre-reset-master branch to master and just mention all issues in the
commit.

Regards,
-- 
Christian

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

[GitHub] maven-wagon pull request #32: ScpWagon file size Integer to Long

[oassuncao]

GitHub user oassuncao opened a pull request:

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

ScpWagon file size Integer to Long

Change filesize to Long as `resource.setContentLength`

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/oassuncao/maven-wagon master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-wagon/pull/32.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #32


commit a72a144a93e08ca85d55a37aebf17ffb510ca4ec
Author: silvioj 
Date:   2017-01-09T12:32:03Z

Change filesize to Long as `resource.setContentLength`




---
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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [DISCUSS] Stop allowing forced pushes to GIT repositories.

[Stephen Connolly]

And INFRA have applied the protections to the master branches of all our
Git repos

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

> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-13288
> filed
>
> On 8 January 2017 at 22:55, Stephen Connolly  com> wrote:
>
>> Master is supposed to be set up that way by infra... if some repositories
>> are not set up that way we should just get infra to fix it
>>
>> On Sun 8 Jan 2017 at 22:47, Christian Schulte  wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> subject says it all. I'd like to request that our GIT repositories are
>>>
>>> setup in a way that a 'git --force push' is not possible. Not pulling
>>>
>>> changes of others in and then force pushing to exchange the remote
>>>
>>> master branch with some other branch should not be possible. In fact, in
>>>
>>> subversion you just could not commit to trunk whithout updating your
>>>
>>> local working copy first and that is something very good about
>>>
>>> subversion. We should not change this just because we switched from
>>>
>>> subversion to git.
>>>
>>>
>>>
>>> Regards,
>>>
>>> --
>>>
>>> Christian
>>>
>>>
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>> --
>> Sent from my phone
>>
>
>

Moving forward on 3.5.0

[Stephen Connolly]

OK, I have updated the versions in JIRA.

Issues which have been agreed in the Big Scrub thread as being accepted for
3.5.0 are all now marked with FixVersion = 3.5.0

Issues which have been proposed for 3.5.0 but have not yet been agreed for
3.5.0 are now all marked with FixVersion = 3.5.0-candidate

Please do not mark any issue with a FixVersion of 3.5.0 until we have had
agreement to put it in scope. It is ok to move things to 3.5.0-candidate

We need to start closing out the decisions on the 3.5.0-candidates.

Also as release manager for 3.5.0 I am requesting that all changes for
master must have a clean build on the full test suite before being merged
to master (I would appreciate a heads up too)

My expectation is that if you committed the changes towards 3.4.0, then you
are responsible for tidying up the commits and preparing a branch for
merging.

-Stephen

Re: [DISCUSS] Stop allowing forced pushes to GIT repositories.

[Stephen Connolly]

https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-13288
filed

On 8 January 2017 at 22:55, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Master is supposed to be set up that way by infra... if some repositories
> are not set up that way we should just get infra to fix it
>
> On Sun 8 Jan 2017 at 22:47, Christian Schulte  wrote:
>
>> Hi,
>>
>>
>>
>> subject says it all. I'd like to request that our GIT repositories are
>>
>> setup in a way that a 'git --force push' is not possible. Not pulling
>>
>> changes of others in and then force pushing to exchange the remote
>>
>> master branch with some other branch should not be possible. In fact, in
>>
>> subversion you just could not commit to trunk whithout updating your
>>
>> local working copy first and that is something very good about
>>
>> subversion. We should not change this just because we switched from
>>
>> subversion to git.
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Christian
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
>

Maven 3.4.0 dropped

[Stephen Connolly]

After some discussion and debate, the Maven developers have agreed [1] to
replan the next release of Maven.

The original plans for Maven 3.4.0 were that it should consist of
effectively a no-op drop in replacement of Eclipse's Aether project (which
has been retired at the Eclipse Foundation) for the migrated code now known
as Apache's Maven Resolver. Additionally the plans called for some other
orthogonal changes around logging colourization and some launcher script
bug fixes.

Due to some misunderstanding, there were quite a number of other changes
introduced which could be seen as modifying how dependencies and classpaths
get built. While we want to get these changes released as bug fixes, it is
also important to us to provide a clear progression of development. Some of
the bugs we want to fix require changes to the resolver code and the
developers feel it is important to mark the baseline of the migrated code
such that it should be a drop-in replacement for 3.3.9.

In that regard we have reset the master branches of the following GIT
repositories to the point in time that corresponds to the 3.3.9 release:

* git://git.apache.org/maven.git was reset to
bce33aa2662a51d18cb00347cf2fb174dc195fb1

* git://git.apache.org/maven-integration-testing.git was reset to
f31241ad6cb6474e559289f1bd7110ea5d5a4fba

* git://git.apache.org/maven-resolver.git was reset to
b74f7a1e8837875b4780199f644119f55d22465d

If you have clones of any of these repositories you will need to update
them as the master branch has been force-pushed.

As there have already been issues closed as fixed in 3.4.0 and a number of
3.4.0-SNAPSHOT releases were distributed for user feedback, it has been
decided to burn the 3.4.0 version number as a signal of the reset. The next
release of Maven will thus be 3.5.0

We have a (mostly) agreed plan for the content of the 3.5.0 release [2]
(there are still some issues being decided on)

As all the content of 3.5.0 has already been developed on the old master
branches (which have been retained as the pre-reset-master branches) it
should be relatively easy to pull each of the agreed changes and merge
them. For this reason we hope to be able to cut a release candidate of
3.5.0 relatively quickly.

The next step will be agreeing the content of next release (which we hope
to have follow 3.5.0 after 6-8 weeks and will either be called 3.5.1 or
3.6.0 depending on the agreed content).

The drive is to get almost all the content that was in the pre-reset-master
released, but in a version history that makes it easier for users to
understand the impact and makes it easier for developers to identify the
potential impact of the changes.

- Stephen

(On behalf of the Apache Maven Project)

[1]:
https://mail-archives.apache.org/mod_mbox/maven-dev/201701.mbox/%3CCA%2BnPnMx-e7kGYy3Hp87v8hLGdhp1q%3DtKLx_6QuZ4kGUqHEBGcw%40mail.gmail.com%3E

[2]: https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017

[RESULT] [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Stephen Connolly]

On 4 January 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 Eclipse's Aether for the code after migration to
> Apache's Maven Resolver plus some other orthogonal changes around logging
> colourization and launcher script bug fixes.
>
> Given that some developer private builds of the current master branch have
> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
> closed with a fixed version of 3.4.0.
>
> For us to release a 3.4.0 with those fixes reverted, could cause confusion
> with our user community.
>
> Additionally the informal practice of keeping existing integration tests
> as RTC has not been followed, leading to some people to question whether
> the integration tests remain valid.
>
> For all the above reasons it is proposed to do *all* the following as an
> whole:
>
> 1. In git://git.apache.org/maven.git we will rename the current master
> branch to `pre-reset-master` and recreate `master` as
> bce33aa2662a51d18cb00347cf2fb174dc195fb1 (https://github.com/apache/
> maven/commit/bce33aa2662a51d18cb00347cf2fb174dc195fb1)
>
> 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the current master branch to `pre-reset-master` and recreate `master` as
> f31241ad6cb6474e559289f1bd7110ea5d5a4fba (https://github.com/apache/
> maven-integration-testing/commit/f31241ad6cb6474e559289f1bd7110ea5d5a4fba)
>
> 3. In git://git.apache.org/maven-resolver.git we will rename the current
> master branch to `pre-reset-master` and recreate `master` as
> b74f7a1e8837875b4780199f644119f55d22465d (https://github.com/apache/
> maven-resolver/commit/b74f7a1e8837875b4780199f644119f55d22465d), i.e. the
> 1.0.x branch
>
> We will then proceed to have (ideally) the original committers cherry-pick
> (and tidy up an squash... if the original committers are not able to assist
> then squashing may not be practicable) those changes that have been agreed
> for 3.5.0 as summarized on the https://cwiki.apache.org/
> confluence/display/MAVEN/Roadmap+2017 wiki page (authorative source of
> the decisions summarized in the wiki page is the mail thread:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E ).
>
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
>
> The vote will be open for at least 72 hours.
>
> The vote will be decided by a simple majority of valid votes cast. There
> is no veto.
>
> The vote is open to all committers.
>
> In addition, for the vote to be valid, there must be at least 3x+1 votes
> from PMC members
>
> [ ] +1: Yes
> [ ] 0:
> [ ] -1: No
>

This vote has passed:

+1: Stephen C, Anders H, Andreas G., Igor F, Robert S, Benson M, Manfred M,
Michael O, Christian S, Guillaume B, Tibor D, Arnaud H, Stephane N, Hervé
B, Karl H M, Olivier L, Dan T.
0:
-1:

I will now proceed with the agreed actions.

Once the reset has been performed I will send a mail to the announce list.

I request that all changes are verified as passing the tests on
https://builds.apache.org/job/maven-jenkinsfile/ before we merge (if you
create a branch with a Jenkinsfile in the root, then the branch should be
picked up and built within 15 minutes (though the build takes closer to 2h
as it runs the tests on unix and windows with java 7 and 8)

One feature per branch is my recommendation, and let's try and get
agreement before we merge each branch

-Stephen

>
> -Stephen
> --
> Sent from my phone
>

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Mark Struberg]

> I like this idea of avoiding force pushing, but I'm not git expert to know 
> exactly if this gives exactly the intended result = start clean and not
> have noise when doing bisects or git blame

It's clean for our own repo but might probably screw up cloned repos as they 
cannot just git-pull anymore.

LieGrue,
strub

> Am 08.01.2017 um 11:41 schrieb Hervé BOUTEMY :
> 
> I like this idea of avoiding force pushing, but I'm not git expert to know 
> exactly if this gives exactly the intended result = start clean and not have 
> noise when doing bisects or git blame
> 
> this technical discussion should probably on a separate email thread, to not 
> pollute the vote thread
> 
> Any git experts to evaluate this implementation strategy?
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 5 janvier 2017, 10:12:10 CET Mark Derricutt a écrit :
>> 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 that ONLY takes one side.
>> Effectively resetting, keeping the fact we did this reversal, and doesn't
>> force everyone to re-clone.
>> 
>> From https://git-scm.com/docs/merge-strategies:
>> 
>> ours: This resolves any number of heads, but the resulting tree of the merge
>> is always that of the current branch head, effectively ignoring all changes
>> from all other branches. It is meant to be used to supersede old
>> development history of side branches. Note that this is different from the
>> -Xours option to the 'recursive' merge strategy.
>> 
>> Would something like this be better than force pushing?
>> 
>> --
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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