Re: [VOTE] Release Apache Commons Text 1.4 based on RC1

2018-06-09 Thread Bruno P. Kinoshita
[ X ] +1 Release these artifacts

Build passing with no errors on

Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T20:58:13+13:00)
Maven home: /opt/apache-maven-3.5.2
Java version: 1.8.0_171, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-127-generic", arch: "amd64", family: "unix"

Using git tag.

Checked signatures and they look OK.


Had a look at the site generated locally, and reports look good too.

Thanks for RM'ing.

Bruno



From: Gary Gregory 
To: Commons Developers List  
Sent: Sunday, 10 June 2018 5:49 AM
Subject: [VOTE] Release Apache Commons Text 1.4 based on RC1



We have fixed quite a few bugs and added some significant enhancements

since Apache Commons Text 1.3 was released, so I would like to release

Apache Commons Text 1.4.


Apache Commons Text 1.4 RC1 is available for review here:

https://dist.apache.org/repos/dist/dev/commons/text (svn revision 27356)


The Git tag commons-text-1.4-RC1 commit for this RC is

d9229655fdb335a9730bef6df789a46faa764b8a which you can browse here:


https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.4-RC1


Maven artifacts are here:


https://repository.apache.org/content/repositories/orgapachecommons-1330/org/apache/commons/commons-text/1.4/


These are the Maven artifacts and their hashes in Nexus:


#Release SHA-1s

#Sat Jun 09 11:15:59 MDT 2018

commons-text-1.4-java-source=47636f3b9ae54bc9618c2e3b1382f1de6297f326

commons-text-1.4-zip.asc=1158f083a0008d92da56cda0065c4cde6c46cb63

commons-text-1.4-javadoc=af2c89fd3df3f00a2dee80df84f8f2d961aa08e7

commons-text-1.4-zip=ca1cc6fbb4e46b44f8bb09b70c9e3a2ae3c5fce8

commons-text-1.4-tar.gz=0dcee421c4e03d6bc098a61a5cdcc90656856611

commons-text-1.4-test-jar=7dfd1a711b16b9379de9ddd9d5c9f9158ca2a38f

commons-text-1.4-jar.asc=24d2e7b8fadd041a3f661798caba035945e15df1

commons-text-1.4-pom.asc=4c97288cab505b297445409bcf79612606b7108b

commons-text-1.4-tar.gz.asc=efe2847068de99a566265c5ff827b127a2159adc


#Release SHA-256s

#Sat Jun 09 11:15:59 MDT 2018

commons-text-1.4-java-source=cfaede7310cb5f669c1c9ad2c0453f65a7f0dc704a4531f634944ecddc03c667

commons-text-1.4-zip.asc=f1f7d3d88f26656c5578d52a3a55e72f07f1ae19250af642336539bd7009

commons-text-1.4-javadoc=765d8236908e1aa7ee9dbbf165fdd993709ffb7d23991ca6be5f8a750b77a381

commons-text-1.4-zip=e4a6c992153faae4f7faff689b899073000364e376736b9746a5d0acb9d8b980

commons-text-1.4-tar.gz=1cb8536c375c3cff66757fd40c2bf878998254ba0a247866a6536bd48ba2e88a

commons-text-1.4-test-jar=078049288745a90d113b2a055471fec30d0c971c79571a9ff1414c9aeb1d70e1

commons-text-1.4-jar.asc=4d044e0f756bcb3487e3a55a58a430363a7df3127c5c68bcd97ef2ccb6b84028

commons-text-1.4-pom.asc=183a60ceeef006955198654556b044ef5baaf1c2f85404ae7c935dd0ddac4bf6

commons-text-1.4-tar.gz.asc=e21ff58d46797e3a9f014f6f37976d9f3beaab08385f549fee2a02b5e41bc574


(no need for .asc hashes!)


I have tested this with 'mvn clean install site' using:


Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;

2018-02-24T12:49:05-07:00)

Maven home: C:\Java\apache-maven-3.5.3\bin\..

Java version: 1.8.0_172, vendor: Oracle Corporation

Java home: C:\Program Files\Java\jdk1.8.0_172\jre

Default locale: en_US, platform encoding: Cp1252

OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"


Details of changes since 1.3 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/text/RELEASE-NOTES.txt


https://dist.apache.org/repos/dist/dev/commons/text/site/changes-report.html


Site:

https://dist.apache.org/repos/dist/dev/commons/text/site

(note some *relative* links are broken and the 1.4 directories are not

yet created - these will be OK once the site is deployed.)


CLIRR Report (compared to 1.3):


https://dist.apache.org/repos/dist/dev/commons/text/site/clirr-report.html


JApiCmp Report (compared to 1.3):

https://dist.apache.org/repos/dist/dev/commons/text/site/japicmp.html


RAT Report:

https://dist.apache.org/repos/dist/dev/commons/text/site/rat-report.html


KEYS:

  https://www.apache.org/dist/commons/KEYS


Please review the release candidate and vote.

This vote will close no sooner that 72 hours from now.


  [ ] +1 Release these artifacts

  [ ] +0 OK, but...

  [ ] -0 OK, but really should fix...

  [ ] -1 I oppose this release because...


Thank you,


Gary Gregory,

Release Manager (using key 2DB4F1EF0FA761ECC4EA935C86FDC7E2A11262CB)

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



[GitHub] commons-cli issue #25: CLI-284: Fix inconsistent behaviour for short and lon...

2018-06-09 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-cli/pull/25
  
Hi @sfuhrm thanks for the pull request. I had a look at the CLI-284 issue 
in JIRA, and also checked out the pull request locally to take a look in 
Eclipse.

I believe we have some tests failing due to this change. See the Travis-CI 
build log, or try running `mvn clean test` locally. I got the following in my 
environment:

```
Tests run: 410, Failures: 0, Errors: 55, Skipped: 54
```

The only other comment I have is about the duplicated code that we have now.

`Option`'s constructor checks for either `opt` or `longOpt` being present. 
But so does `Option$Builder#build()`.

What about moving the 

```java
if (opt == null && longOpt == null)
{
throw new IllegalArgumentException("Either opt or longOpt must be 
specified");
}
```

check to `OptionValidator`? Maybe that way we avoid having the same if in 
two places, and running the risk of someday changing one without changing the 
other (though tests should catch it).

Thanks!


---

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



[GitHub] commons-cli issue #25: CLI-284: Fix inconsistent behaviour for short and lon...

2018-06-09 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-cli/pull/25
  
Hi @sfuhrm thanks for the pull request. I had a look at the CLI-284 issue 
in JIRA, and also checked out the pull request locally to take a look in 
Eclipse.

I believe we have some tests failing due to this change. See the Travis-CI 
build log, or try running `mvn clean test` locally. I got the following in my 
environment:

```
Tests run: 410, Failures: 0, Errors: 55, Skipped: 54
```

The only other comment I have is about the duplicated code that we have now.

`Option`'s constructor checks for either `opt` or `longOpt` being present. 
But so does `Option$Builder#build()`.

What about moving the 

```java
if (opt == null && longOpt == null)
{
throw new IllegalArgumentException("Either opt or longOpt must be 
specified");
}
```

check to `OptionValidator`? Maybe that way we avoid having the same if in 
two places, and running the risk of someday changing one without changing the 
other (though tests should catch it).

Thanks!


---

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



[GitHub] commons-collections pull request #38: COLLECTIONS-681: New unit test for Mul...

2018-06-09 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/38


---

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



[GitHub] commons-collections pull request #38: COLLECTIONS-681: New unit test for Mul...

2018-06-09 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/38


---

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



Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

2018-06-09 Thread Bruno P. Kinoshita
Yes, that's my understanding. We would use require static on java.desktop, but 
users wouldn't have any issues as long as they did not use the version of the 
class that requires java.desktop.

If the user want/needs to use those classes, then they have to add the 
dependency to java.desktop in their code.


Otherwise, the user just would have to update his/her code to use the new 
classes (the pull request is about providing this alternative).


Not perfect, but after a few releases (1? couple? major?) we can delete the 
deprecated classes and tests, remove the require static, and forget about this 
issue (-:


Bruno


From: Gary Gregory 
To: Commons Developers List ; Bruno P. Kinoshita 
 
Sent: Sunday, 10 June 2018 10:56 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop 
(Was: Re: [LANG] Thoughts about Lang 4.0)



So the dependency on desktop is declared as optional but it still exists?

Gary

On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita
 wrote:

> Hi all,
>
> There is a patch [1] for LANG-1339 [2] that I would like to merge. The
> discussion around this issue can be found in the rest of this e-mail thread.
>
> The patch basically deprecates the existing classes that depend on
> java.desktop, and provide alternative implementations. The previous classes
> used java.desktop classes for the PropertyChangeListener. And the
> alternative ones instead use Java 7's java.util.Observer.
>
>
> This will make it easier to provide [lang] as java 9, without requiring
> users to include a dependency to java.desktop.
> Planning to merge it during the next week if there are no objections here.
>
> Thanks,
> Bruno
>
>
> [1] https://github.com/apache/commons-lang/pull/275
>
> [2] https://issues.apache.org/jira/browse/LANG-1339
>
>
>
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Monday, 5 June 2017 10:49 PM
> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
> (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
>
> > Am 25.05.2017 um 18:23 schrieb Oliver Heger <
> oliver.he...@oliver-heger.de>:
> >
> >
> >
> > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >> On 23 May 2017 at 17:17, sebb  wrote:
>  Yes, the
>  code compiles and both can be on the classpath, but it is a pain to
>  use, just a different kind of hell.
> >>>
> >>> I don't see what the problem is here.
> >>
> >> Library A that depends on lang3 returns a Pair.
> >> Library B that depends on lang4 takes a Pair.
> >> Application cannot pass Pair from A to the B without conversion.
> >>
> >> My point is that it is possible to over-worry about jar hell.
> >> Joda-Time removed some methods when it went from v1.x to v2.x, but
> >> didn't change package name or maven co-ordinates. It was far more
> >> important that end-users didn't have two different LocalDate classes
> >> (a problem that couldn't be avoided when moving to Java 8). I've never
> >> seen any feedback about the incompatibility causing jar hell.
> >>
> >> The same is true here. It is vital to think properly about which is
> >> the worse choice, not just assume that jar hell must always be
> >> avoided.
> >>
> >> I remain completely unconvinced that removing these two problematic
> >> methods justifies the lang4 package name, forcing end-users to have
> >> three copies of the library on the classpath. It should need much,
> >> much more to justify lang4 package name. In fact I've yet to hear
> >> anything else much in this thread that justifies a major release.
> >
> > I also think that a new major release just to fix this problem would be
> > overkill and cause clients even more trouble.
> >
> > Would the following approach work as a compromise:
> >
> > - [lang] declares an optional dependency to the desktop module.
> > - All affected classes (AbstractCircuitBreaker and its two sub classes)
> > are marked as deprecated.
> > - Copies are created from the original classes with slightly changed
> > names or in a new package (tbd). These copies use a new change listener
> > mechanism.
> >
> > IIUC, the resulting [lang] module can now be used without the dependency
> > to desktop when the new classes are used. The dependency will only be
> > needed for the deprecated versions.
>
> Let’s do it like this. Sounds like the right way to me.
>
> Benedikt
>
> >
> > Oliver
> >
> >>
> >> Stephen
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org

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

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

2018-06-09 Thread Gary Gregory
So the dependency on desktop is declared as optional but it still exists?

Gary

On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita
 wrote:

> Hi all,
>
> There is a patch [1] for LANG-1339 [2] that I would like to merge. The
> discussion around this issue can be found in the rest of this e-mail thread.
>
> The patch basically deprecates the existing classes that depend on
> java.desktop, and provide alternative implementations. The previous classes
> used java.desktop classes for the PropertyChangeListener. And the
> alternative ones instead use Java 7's java.util.Observer.
>
>
> This will make it easier to provide [lang] as java 9, without requiring
> users to include a dependency to java.desktop.
> Planning to merge it during the next week if there are no objections here.
>
> Thanks,
> Bruno
>
>
> [1] https://github.com/apache/commons-lang/pull/275
>
> [2] https://issues.apache.org/jira/browse/LANG-1339
>
>
>
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Monday, 5 June 2017 10:49 PM
> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
> (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
>
> > Am 25.05.2017 um 18:23 schrieb Oliver Heger <
> oliver.he...@oliver-heger.de>:
> >
> >
> >
> > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >> On 23 May 2017 at 17:17, sebb  wrote:
>  Yes, the
>  code compiles and both can be on the classpath, but it is a pain to
>  use, just a different kind of hell.
> >>>
> >>> I don't see what the problem is here.
> >>
> >> Library A that depends on lang3 returns a Pair.
> >> Library B that depends on lang4 takes a Pair.
> >> Application cannot pass Pair from A to the B without conversion.
> >>
> >> My point is that it is possible to over-worry about jar hell.
> >> Joda-Time removed some methods when it went from v1.x to v2.x, but
> >> didn't change package name or maven co-ordinates. It was far more
> >> important that end-users didn't have two different LocalDate classes
> >> (a problem that couldn't be avoided when moving to Java 8). I've never
> >> seen any feedback about the incompatibility causing jar hell.
> >>
> >> The same is true here. It is vital to think properly about which is
> >> the worse choice, not just assume that jar hell must always be
> >> avoided.
> >>
> >> I remain completely unconvinced that removing these two problematic
> >> methods justifies the lang4 package name, forcing end-users to have
> >> three copies of the library on the classpath. It should need much,
> >> much more to justify lang4 package name. In fact I've yet to hear
> >> anything else much in this thread that justifies a major release.
> >
> > I also think that a new major release just to fix this problem would be
> > overkill and cause clients even more trouble.
> >
> > Would the following approach work as a compromise:
> >
> > - [lang] declares an optional dependency to the desktop module.
> > - All affected classes (AbstractCircuitBreaker and its two sub classes)
> > are marked as deprecated.
> > - Copies are created from the original classes with slightly changed
> > names or in a new package (tbd). These copies use a new change listener
> > mechanism.
> >
> > IIUC, the resulting [lang] module can now be used without the dependency
> > to desktop when the new classes are used. The dependency will only be
> > needed for the deprecated versions.
>
> Let’s do it like this. Sounds like the right way to me.
>
> Benedikt
>
> >
> > Oliver
> >
> >>
> >> Stephen
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

2018-06-09 Thread Bruno P. Kinoshita
Hi all,

There is a patch [1] for LANG-1339 [2] that I would like to merge. The 
discussion around this issue can be found in the rest of this e-mail thread.

The patch basically deprecates the existing classes that depend on 
java.desktop, and provide alternative implementations. The previous classes 
used java.desktop classes for the PropertyChangeListener. And the alternative 
ones instead use Java 7's java.util.Observer.


This will make it easier to provide [lang] as java 9, without requiring users 
to include a dependency to java.desktop.
Planning to merge it during the next week if there are no objections here.

Thanks,
Bruno


[1] https://github.com/apache/commons-lang/pull/275

[2] https://issues.apache.org/jira/browse/LANG-1339



From: Benedikt Ritter 
To: Commons Developers List  
Sent: Monday, 5 June 2017 10:49 PM
Subject: [LANG] Java 9 problems because of dependencies to java.desktop (Was: 
Re: [LANG] Thoughts about Lang 4.0)




> Am 25.05.2017 um 18:23 schrieb Oliver Heger :
> 
> 
> 
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb  wrote:
 Yes, the
 code compiles and both can be on the classpath, but it is a pain to
 use, just a different kind of hell.
>>> 
>>> I don't see what the problem is here.
>> 
>> Library A that depends on lang3 returns a Pair.
>> Library B that depends on lang4 takes a Pair.
>> Application cannot pass Pair from A to the B without conversion.
>> 
>> My point is that it is possible to over-worry about jar hell.
>> Joda-Time removed some methods when it went from v1.x to v2.x, but
>> didn't change package name or maven co-ordinates. It was far more
>> important that end-users didn't have two different LocalDate classes
>> (a problem that couldn't be avoided when moving to Java 8). I've never
>> seen any feedback about the incompatibility causing jar hell.
>> 
>> The same is true here. It is vital to think properly about which is
>> the worse choice, not just assume that jar hell must always be
>> avoided.
>> 
>> I remain completely unconvinced that removing these two problematic
>> methods justifies the lang4 package name, forcing end-users to have
>> three copies of the library on the classpath. It should need much,
>> much more to justify lang4 package name. In fact I've yet to hear
>> anything else much in this thread that justifies a major release.
> 
> I also think that a new major release just to fix this problem would be
> overkill and cause clients even more trouble.
> 
> Would the following approach work as a compromise:
> 
> - [lang] declares an optional dependency to the desktop module.
> - All affected classes (AbstractCircuitBreaker and its two sub classes)
> are marked as deprecated.
> - Copies are created from the original classes with slightly changed
> names or in a new package (tbd). These copies use a new change listener
> mechanism.
> 
> IIUC, the resulting [lang] module can now be used without the dependency
> to desktop when the new classes are used. The dependency will only be
> needed for the deprecated versions.

Let’s do it like this. Sounds like the right way to me.

Benedikt

> 
> Oliver
> 
>> 
>> Stephen
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org

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


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

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



[text] commit Mail subject prefix (was: [50/50] [abbrv] [text] Prepare for releasing 1.4.)

2018-06-09 Thread Bernd Eckenfels

Hello,

Is there a possible setup problem of the subject prefix for [text] commit 
mails? Looks like [abrev] is a left over from some sort of template? Or what it 
is supposed to mean?

Can this be fixed by ourself or dome need a infra ticket?

Gruss
Bernd
--
http://bernd.eckenfels.net
_
From: ggreg...@apache.org
Sent: Samstag, Juni 9, 2018 6:48 PM
Subject: [50/50] [abbrv] [text] Prepare for releasing 1.4.
To: 









Re: [all] - git: prevent unnecessary merge commits?

2018-06-09 Thread Bernd Eckenfels
+1 linear commits and branch.autosetuprebase always

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Emmanuel Bourg 
Sent: Saturday, June 9, 2018 11:54:01 PM
To: Commons Developers List
Subject: Re: [all] - git: prevent unnecessary merge commits?

+1, I prefer linear commit histories too.

Emmanuel Bourg

Le 09/06/2018 à 10:53, Pascal Schumacher a écrit :
> Hello everybody,
>
> in my opinion it is a good practice to always use the "--rebase" option
> when using "git pull". This keeps the history free of unnecessary merge
> commits like "Merge branch 'master' of
> https://git-wip-us.apache.org/repo...;.
>
> You can also tell git to automatically rebase when pulling:
>
> git config --global pull.rebase true
>
> What do you think?
>
> Cheers,
>
> Pascal
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


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



Re: [all] - git: prevent unnecessary merge commits?

2018-06-09 Thread Emmanuel Bourg
+1, I prefer linear commit histories too.

Emmanuel Bourg

Le 09/06/2018 à 10:53, Pascal Schumacher a écrit :
> Hello everybody,
> 
> in my opinion it is a good practice to always use the "--rebase" option
> when using "git pull". This keeps the history free of unnecessary merge
> commits like "Merge branch 'master' of
> https://git-wip-us.apache.org/repo...;.
> 
> You can also tell git to automatically rebase when pulling:
> 
> git config --global pull.rebase true
> 
> What do you think?
> 
> Cheers,
> 
> Pascal
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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



Re: [release plugin] error when a file already exists in SVN

2018-06-09 Thread Rob Tompkins
Hm...that directory isn’t part of the site build, I checked it in to keep the 
older versions of the api available for google indexing. I’ll have to fiddle 
around with the plugin to overcome the error. 

> On Jun 9, 2018, at 1:18 PM, Gary Gregory  wrote:
> 
> I deleted the files in dist SVN to handle the previous error.
> But now, here is another:
> 
> [INFO] --- commons-release-plugin:1.3-SNAPSHOT:stage-distributions
> (stage-distributions) @ commons-text ---
> [INFO] Preparing to stage distributions
> [INFO] Checking out dist from: scm:svn:
> https://dist.apache.org/repos/dist/dev/commons/text
> Executing: cmd.exe /X /C "svn --username ggregory --no-auth-cache
> --non-interactive checkout
> https://dist.apache.org/repos/dist/dev/commons/text
> C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm"
> Working directory:
> C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin
> [INFO] Copying RELEASE-NOTES.txt to working directory.
> Executing: cmd.exe /X /C "svn add --parents --non-recursive --targets
> C:\Users\ggregory\AppData\Local\Temp\maven-scm-7797893434645231366-targets"
> Working directory:
> C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm
> [ERROR] Adding dist files failed: svn: E155007:
> 'C:\vcs\git\apache\commons\commons-text\target\site\apidocs' is not a
> working copy
> 
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 03:32 min
> [INFO] Finished at: 2018-06-09T11:17:02-06:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.commons:commons-release-plugin:1.3-SNAPSHOT:stage-distributions
> (stage-distributions) on project commons-text: Adding dist files failed:
> svn: E155007: 'C:\vcs\git\apache\commons\commons-text\target\site\apidocs'
> is not a working copy
> [ERROR]
> 
> Thoughts?
> 
> Gary
> 
> 
> On Sat, Jun 9, 2018 at 11:08 AM, Gary Gregory 
> wrote:
> 
>> Hi Rob:
>> 
>> We should handle this case:
>> 
>> [INFO] 
>> 
>> [INFO] BUILD FAILURE
>> [INFO] 
>> 
>> [INFO] Total time: 04:12 min
>> [INFO] Finished at: 2018-06-09T11:07:28-06:00
>> [INFO] 
>> 
>> [ERROR] Failed to execute goal org.apache.commons:commons-
>> release-plugin:1.2:stage-distributions (stage-distributions) on project
>> commons-text: Adding dist files failed: svn: warning: W150002:
>> 'C:\vcs\git\apache\commons\commons-text\target\commons-
>> release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz' is already under
>> version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\
>> commons-text-1.4-bin.tar.gz.asc' is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\
>> commons-text-1.4-bin.tar.gz.md5' is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\
>> commons-text-1.4-bin.tar.gz.sha1' is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip'
>> is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.asc'
>> is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.md5'
>> is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.sha1'
>> is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz'
>> is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\source\
>> commons-text-1.4-src.tar.gz.asc' is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\source\
>> commons-text-1.4-src.tar.gz.md5' is already under version control
>> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
>> commons-text\target\commons-release-plugin\scm\source\
>> commons-text-1.4-src.tar.gz.sha1' is already under version control
>> [ERROR] svn: warning: W150002: 

[GitHub] commons-collections issue #38: COLLECTIONS-681: New unit test for MultiSetUt...

2018-06-09 Thread coveralls
Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/38
  

[![Coverage 
Status](https://coveralls.io/builds/17408068/badge)](https://coveralls.io/builds/17408068)

Coverage increased (+0.07%) to 86.644% when pulling 
**d0fefc5b50aeb7acbad5fbc4b36266d7ed6a855d on sfuhrm:MultiSetUtilsTest** into 
**13ba1cc91ea441ab012fa4e9724fbca397f1b1cf on apache:master**.



---

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



[GitHub] commons-collections pull request #38: COLLECTIONS-681: New unit test for Mul...

2018-06-09 Thread sfuhrm
GitHub user sfuhrm opened a pull request:

https://github.com/apache/commons-collections/pull/38

COLLECTIONS-681: New unit test for MultiSetUtils

A unit test for the MultiSetUtils. The MultiSetUtils had no tests at all, 
so this will improve the overall coverage.

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

$ git pull https://github.com/sfuhrm/commons-collections MultiSetUtilsTest

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

https://github.com/apache/commons-collections/pull/38.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 #38


commit d0fefc5b50aeb7acbad5fbc4b36266d7ed6a855d
Author: Stephan Fuhrmann 
Date:   2018-06-09T18:11:59Z

New unit test for MultiSetUtils




---

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



[VOTE] Release Apache Commons Text 1.4 based on RC1

2018-06-09 Thread Gary Gregory
We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Text 1.3 was released, so I would like to release
Apache Commons Text 1.4.

Apache Commons Text 1.4 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/text (svn revision 27356)

The Git tag commons-text-1.4-RC1 commit for this RC is
d9229655fdb335a9730bef6df789a46faa764b8a which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.4-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1330/org/apache/commons/commons-text/1.4/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-1s
#Sat Jun 09 11:15:59 MDT 2018
commons-text-1.4-java-source=47636f3b9ae54bc9618c2e3b1382f1de6297f326
commons-text-1.4-zip.asc=1158f083a0008d92da56cda0065c4cde6c46cb63
commons-text-1.4-javadoc=af2c89fd3df3f00a2dee80df84f8f2d961aa08e7
commons-text-1.4-zip=ca1cc6fbb4e46b44f8bb09b70c9e3a2ae3c5fce8
commons-text-1.4-tar.gz=0dcee421c4e03d6bc098a61a5cdcc90656856611
commons-text-1.4-test-jar=7dfd1a711b16b9379de9ddd9d5c9f9158ca2a38f
commons-text-1.4-jar.asc=24d2e7b8fadd041a3f661798caba035945e15df1
commons-text-1.4-pom.asc=4c97288cab505b297445409bcf79612606b7108b
commons-text-1.4-tar.gz.asc=efe2847068de99a566265c5ff827b127a2159adc

#Release SHA-256s
#Sat Jun 09 11:15:59 MDT 2018
commons-text-1.4-java-source=cfaede7310cb5f669c1c9ad2c0453f65a7f0dc704a4531f634944ecddc03c667
commons-text-1.4-zip.asc=f1f7d3d88f26656c5578d52a3a55e72f07f1ae19250af642336539bd7009
commons-text-1.4-javadoc=765d8236908e1aa7ee9dbbf165fdd993709ffb7d23991ca6be5f8a750b77a381
commons-text-1.4-zip=e4a6c992153faae4f7faff689b899073000364e376736b9746a5d0acb9d8b980
commons-text-1.4-tar.gz=1cb8536c375c3cff66757fd40c2bf878998254ba0a247866a6536bd48ba2e88a
commons-text-1.4-test-jar=078049288745a90d113b2a055471fec30d0c971c79571a9ff1414c9aeb1d70e1
commons-text-1.4-jar.asc=4d044e0f756bcb3487e3a55a58a430363a7df3127c5c68bcd97ef2ccb6b84028
commons-text-1.4-pom.asc=183a60ceeef006955198654556b044ef5baaf1c2f85404ae7c935dd0ddac4bf6
commons-text-1.4-tar.gz.asc=e21ff58d46797e3a9f014f6f37976d9f3beaab08385f549fee2a02b5e41bc574

(no need for .asc hashes!)

I have tested this with 'mvn clean install site' using:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_172\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 1.3 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/text/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/text/site/changes-report.html

Site:
https://dist.apache.org/repos/dist/dev/commons/text/site
(note some *relative* links are broken and the 1.4 directories are not
yet created - these will be OK once the site is deployed.)

CLIRR Report (compared to 1.3):

https://dist.apache.org/repos/dist/dev/commons/text/site/clirr-report.html

JApiCmp Report (compared to 1.3):
https://dist.apache.org/repos/dist/dev/commons/text/site/japicmp.html

RAT Report:
https://dist.apache.org/repos/dist/dev/commons/text/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 2DB4F1EF0FA761ECC4EA935C86FDC7E2A11262CB)


[GitHub] commons-collections issue #37: COLLECTIONS-673: Fix inspired by the Guava pa...

2018-06-09 Thread coveralls
Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/37
  

[![Coverage 
Status](https://coveralls.io/builds/17407790/badge)](https://coveralls.io/builds/17407790)

Coverage increased (+0.007%) to 86.582% when pulling 
**faf27f611f4429c77a800124b5fb6f641f871c0f on sfuhrm:COLLECTIONS-673** into 
**13ba1cc91ea441ab012fa4e9724fbca397f1b1cf on apache:master**.



---

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



[GitHub] commons-collections pull request #37: COLLECTIONS-673: Fix inspired by the G...

2018-06-09 Thread sfuhrm
GitHub user sfuhrm opened a pull request:

https://github.com/apache/commons-collections/pull/37

COLLECTIONS-673: Fix inspired by the Guava partition() implementation

A fix for the COLLECTIONS-673 bug and a unit test proving the fix for the 
shown defect.

See https://issues.apache.org/jira/browse/COLLECTIONS-673

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

$ git pull https://github.com/sfuhrm/commons-collections COLLECTIONS-673

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

https://github.com/apache/commons-collections/pull/37.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 #37


commit faf27f611f4429c77a800124b5fb6f641f871c0f
Author: Stephan Fuhrmann 
Date:   2018-06-09T17:30:13Z

COLLECTIONS-673: Fix inspired by the Guava partition() implementation




---

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



Re: [release plugin] error when a file already exists in SVN

2018-06-09 Thread Gary Gregory
I deleted the files in dist SVN to handle the previous error.
 But now, here is another:

[INFO] --- commons-release-plugin:1.3-SNAPSHOT:stage-distributions
(stage-distributions) @ commons-text ---
[INFO] Preparing to stage distributions
[INFO] Checking out dist from: scm:svn:
https://dist.apache.org/repos/dist/dev/commons/text
Executing: cmd.exe /X /C "svn --username ggregory --no-auth-cache
--non-interactive checkout
https://dist.apache.org/repos/dist/dev/commons/text
C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm"
Working directory:
C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin
[INFO] Copying RELEASE-NOTES.txt to working directory.
Executing: cmd.exe /X /C "svn add --parents --non-recursive --targets
C:\Users\ggregory\AppData\Local\Temp\maven-scm-7797893434645231366-targets"
Working directory:
C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm
[ERROR] Adding dist files failed: svn: E155007:
'C:\vcs\git\apache\commons\commons-text\target\site\apidocs' is not a
working copy

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 03:32 min
[INFO] Finished at: 2018-06-09T11:17:02-06:00
[INFO]

[ERROR] Failed to execute goal
org.apache.commons:commons-release-plugin:1.3-SNAPSHOT:stage-distributions
(stage-distributions) on project commons-text: Adding dist files failed:
svn: E155007: 'C:\vcs\git\apache\commons\commons-text\target\site\apidocs'
is not a working copy
[ERROR]

Thoughts?

Gary


On Sat, Jun 9, 2018 at 11:08 AM, Gary Gregory 
wrote:

> Hi Rob:
>
> We should handle this case:
>
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 04:12 min
> [INFO] Finished at: 2018-06-09T11:07:28-06:00
> [INFO] 
> 
> [ERROR] Failed to execute goal org.apache.commons:commons-
> release-plugin:1.2:stage-distributions (stage-distributions) on project
> commons-text: Adding dist files failed: svn: warning: W150002:
> 'C:\vcs\git\apache\commons\commons-text\target\commons-
> release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz' is already under
> version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.asc' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.md5' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.sha1' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.asc'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.md5'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.sha1'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.asc' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.md5' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.sha1' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.asc'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> 

Re: [release plugin] error when a file already exists in SVN

2018-06-09 Thread Gary Gregory
For this issue, we should nuke the whole folder just after checking it
out...

Gary

On Sat, Jun 9, 2018 at 11:08 AM, Gary Gregory 
wrote:

> Hi Rob:
>
> We should handle this case:
>
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 04:12 min
> [INFO] Finished at: 2018-06-09T11:07:28-06:00
> [INFO] 
> 
> [ERROR] Failed to execute goal org.apache.commons:commons-
> release-plugin:1.2:stage-distributions (stage-distributions) on project
> commons-text: Adding dist files failed: svn: warning: W150002:
> 'C:\vcs\git\apache\commons\commons-text\target\commons-
> release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz' is already under
> version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.asc' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.md5' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\
> commons-text-1.4-bin.tar.gz.sha1' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.asc'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.md5'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.sha1'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.asc' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.md5' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\
> commons-text-1.4-src.tar.gz.sha1' is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.asc'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.md5'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.sha1'
> is already under version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\site.zip' is already under
> version control
> [ERROR] svn: warning: W150002: 'C:\vcs\git\apache\commons\
> commons-text\target\commons-release-plugin\scm\RELEASE-NOTES.txt' is
> already under version control
> [ERROR] svn: E29: Could not add all targets because some targets are
> already versioned
> [ERROR] svn: E29: Illegal target for the requested operation
> [ERROR]
>
> Thank you,
> Gary
>


[release plugin] error when a file already exists in SVN

2018-06-09 Thread Gary Gregory
Hi Rob:

We should handle this case:

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 04:12 min
[INFO] Finished at: 2018-06-09T11:07:28-06:00
[INFO]

[ERROR] Failed to execute goal
org.apache.commons:commons-release-plugin:1.2:stage-distributions
(stage-distributions) on project commons-text: Adding dist files failed:
svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz.asc'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz.md5'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.tar.gz.sha1'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.asc'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.md5'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\binaries\commons-text-1.4-bin.zip.sha1'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz.asc'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz.md5'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.tar.gz.sha1'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.asc'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.md5'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\source\commons-text-1.4-src.zip.sha1'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\site.zip'
is already under version control
[ERROR] svn: warning: W150002:
'C:\vcs\git\apache\commons\commons-text\target\commons-release-plugin\scm\RELEASE-NOTES.txt'
is already under version control
[ERROR] svn: E29: Could not add all targets because some targets are
already versioned
[ERROR] svn: E29: Illegal target for the requested operation
[ERROR]

Thank you,
Gary


[DBCP] Release 2.4.0

2018-06-09 Thread Gary Gregory
Hi All:

I'd like to release DBCP 2.4.0 ASAP. Please review what you feel like
reviewing...

Gary


[GitHub] commons-pool issue #5: Delete repeated call startEvictor

2018-06-09 Thread garydgregory
Github user garydgregory commented on the issue:

https://github.com/apache/commons-pool/pull/5
  
Thank you for your patch. In git master now.


---

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



[GitHub] commons-pool pull request #5: Delete repeated call startEvictor

2018-06-09 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-pool/pull/5


---

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



Re: rolling a commons-weaver release?

2018-06-09 Thread Matt Benson
Site needs some work before it will build. ISTR that the japicmp config
needs tweaking.

Matt

On Sat, Jun 9, 2018, 7:36 AM Gary Gregory  wrote:

> Go for it.
>
> Gary
>
> On Sat, Jun 9, 2018, 02:32 Mark Struberg 
> wrote:
>
> > Hi folks!
> >
> > I'd like to run a commons-weaver release.
> > We need it for Apache BVal.
> >
> > The new version adds Java9+10 support, etc
> >
> > Any objections?
> >
> >
> > LieGrue,
> > strub
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>


Re: rolling a commons-weaver release?

2018-06-09 Thread Gary Gregory
Go for it.

Gary

On Sat, Jun 9, 2018, 02:32 Mark Struberg  wrote:

> Hi folks!
>
> I'd like to run a commons-weaver release.
> We need it for Apache BVal.
>
> The new version adds Java9+10 support, etc
>
> Any objections?
>
>
> LieGrue,
> strub
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


[GitHub] commons-cli pull request #25: CLI-284: Fix inconsistent behaviour for short ...

2018-06-09 Thread sfuhrm
GitHub user sfuhrm opened a pull request:

https://github.com/apache/commons-cli/pull/25

CLI-284: Fix inconsistent behaviour for short and long name == null

Fix for https://issues.apache.org/jira/browse/CLI-284


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

$ git pull https://github.com/sfuhrm/commons-cli master

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

https://github.com/apache/commons-cli/pull/25.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 #25


commit 4a2e95d01e39d89ffb2711f0b13f0020fef0d561
Author: Stephan Fuhrmann 
Date:   2018-06-09T11:24:13Z

CLI-284: Fix inconsistent behaviour for short and long name == null




---

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



Re: [all] - git: prevent unnecessary merge commits?

2018-06-09 Thread ajs6f
+1. Unless there is a specific reason to incur a merge commit, it's generally 
noise.

ajs6f

> On Jun 9, 2018, at 5:03 AM, Bruno P. Kinoshita 
>  wrote:
> 
> Hi Pascal,
> 
> Apache OpenNLP uses that approach whenever possible 
> (http://opennlp.apache.org/using-git.html). I like the way the commit tree 
> looks after a while. Sometimes it's not practical, especially when receiving 
> patches from external contributors (developers can still check-out code 
> locally and squash commits & rebase, but sometimes it can get messy and take 
> much longer).
> 
> I'm +1 for recommending this as a good practice. In my workflow I normally 
> `fetch` + `rebase`, instead of `pull`.
> 
> Cheers,
> Bruno
> 
> 
> 
> 
> 
> From: Pascal Schumacher 
> To: Commons Developers List  
> Sent: Saturday, 9 June 2018 8:53 PM
> Subject: [all] - git: prevent unnecessary merge commits?
> 
> 
> 
> Hello everybody,
> 
> 
> in my opinion it is a good practice to always use the "--rebase" option 
> 
> when using "git pull". This keeps the history free of unnecessary merge 
> 
> commits like "Merge branch 'master' of 
> 
> https://git-wip-us.apache.org/repo...;.
> 
> 
> You can also tell git to automatically rebase when pulling:
> 
> 
> git config --global pull.rebase true
> 
> 
> What do you think?
> 
> 
> Cheers,
> 
> 
> Pascal
> 
> 
> 
> -
> 
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> 
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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



Re: rolling a commons-weaver release?

2018-06-09 Thread Romain Manni-Bucau
+1

Le sam. 9 juin 2018 10:32, Mark Struberg  a
écrit :

> Hi folks!
>
> I'd like to run a commons-weaver release.
> We need it for Apache BVal.
>
> The new version adds Java9+10 support, etc
>
> Any objections?
>
>
> LieGrue,
> strub
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [all] - git: prevent unnecessary merge commits?

2018-06-09 Thread Bruno P. Kinoshita
Hi Pascal,

Apache OpenNLP uses that approach whenever possible 
(http://opennlp.apache.org/using-git.html). I like the way the commit tree 
looks after a while. Sometimes it's not practical, especially when receiving 
patches from external contributors (developers can still check-out code locally 
and squash commits & rebase, but sometimes it can get messy and take much 
longer).

I'm +1 for recommending this as a good practice. In my workflow I normally 
`fetch` + `rebase`, instead of `pull`.

Cheers,
Bruno





From: Pascal Schumacher 
To: Commons Developers List  
Sent: Saturday, 9 June 2018 8:53 PM
Subject: [all] - git: prevent unnecessary merge commits?



Hello everybody,


in my opinion it is a good practice to always use the "--rebase" option 

when using "git pull". This keeps the history free of unnecessary merge 

commits like "Merge branch 'master' of 

https://git-wip-us.apache.org/repo...;.


You can also tell git to automatically rebase when pulling:


git config --global pull.rebase true


What do you think?


Cheers,


Pascal



-

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

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

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



[all] - git: prevent unnecessary merge commits?

2018-06-09 Thread Pascal Schumacher

Hello everybody,

in my opinion it is a good practice to always use the "--rebase" option 
when using "git pull". This keeps the history free of unnecessary merge 
commits like "Merge branch 'master' of 
https://git-wip-us.apache.org/repo...;.


You can also tell git to automatically rebase when pulling:

git config --global pull.rebase true

What do you think?

Cheers,

Pascal


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



rolling a commons-weaver release?

2018-06-09 Thread Mark Struberg
Hi folks!

I'd like to run a commons-weaver release.
We need it for Apache BVal.

The new version adds Java9+10 support, etc

Any objections?


LieGrue,
strub


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



[GitHub] commons-io pull request #63: Travis: Add oraclejdk10

2018-06-09 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-io/pull/63


---

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



[GitHub] commons-io pull request #63: Travis: Add oraclejdk10

2018-06-09 Thread PascalSchumacher
GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-io/pull/63

Travis: Add oraclejdk10



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

$ git pull https://github.com/PascalSchumacher/commons-io travis_java_10

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

https://github.com/apache/commons-io/pull/63.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 #63


commit 6aeb140ebd5fb087a881cfadde2b00c2c987ab92
Author: Pascal Schumacher 
Date:   2018-06-09T07:59:39Z

Travis: Add oraclejdk10




---

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