[GitHub] [commons-daemon] arturobernalg opened a new pull request #22: Minor Improvement:

[GitBox]

arturobernalg opened a new pull request #22:
URL: https://github.com/apache/commons-daemon/pull/22


   * Add final
   * Remove redundant initializer
   * Replace String in loop by StringBuilder
   * Use Empty  array



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-imaging] kinow commented on a change in pull request #114: imaging.color extension/fix. More precision, DIN99b + DIN99o added to ColorConversion, division by zero error fixed.

[GitBox]

kinow commented on a change in pull request #114:
URL: https://github.com/apache/commons-imaging/pull/114#discussion_r559898056



##
File path: src/main/java/org/apache/commons/imaging/color/ColorCieLch.java
##
@@ -19,10 +19,14 @@
 /**
  * Represents a color in the CIELCH color space.
  *
- * Contains the constant values for black, white, red,
- * green, and blue.
+ * 
+ * Contains the constant values for black, white, red,
+ * green, and blue.
+ * 
+ * Changes: H renamed to h.

Review comment:
   The changes must be documented in a JIRA issue and linked to the 
changelog (i.e. the JIRA number is added to src/changes/changes.xml later, used 
to generate the changes report from the project site).

##
File path: src/main/java/org/apache/commons/imaging/color/ColorConversions.java
##
@@ -643,28 +602,30 @@ private static int convertRGBtoRGB(int red, int green, 
int blue) {
 return rgb;
 }
 
+private static int convertRGBtoRGB(final Color color) {
+return color.getRGB() | 0xff << 24; // alpha channel always opaque
+}

Review comment:
   Ideally we would limit awt use, or remove it, so that users can use 
Imaging for Android apps too (we have one user with a workaround on his code at 
the moment). Unless that makes maintaining the code extremely difficult, in 
which case we can just try to figure out another way to provide a version 
compatible with Android...





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-imaging] dependabot[bot] commented on pull request #115: Bump spotbugs-maven-plugin from 4.1.4 to 4.2.0

[GitBox]

dependabot[bot] commented on pull request #115:
URL: https://github.com/apache/commons-imaging/pull/115#issuecomment-762585027


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-imaging] kinow closed pull request #115: Bump spotbugs-maven-plugin from 4.1.4 to 4.2.0

[GitBox]

kinow closed pull request #115:
URL: https://github.com/apache/commons-imaging/pull/115


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code

[Alan Moffat (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267579#comment-17267579
 ] 

Alan Moffat commented on IO-686:


The original Javadoc explicitly called out the @throws NullPointerExceotion for 
a null inputstream (see initial comment on this bug report).
Based on what you’ve said I would expect this in the Javadoc on master but it’s 
not. I feel that this should be added in 

> IOUtils.toByteArray(InputStream) Javadoc does not match code
> 
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method 
> should throw an exception, however it is producing an empty byte array 
> instead.
> {code:java}
> /**
>  * Gets the contents of an InputStream as a byte[].
>  * 
>  * This method buffers the input internally, so there is no need to use a
>  * BufferedInputStream.
>  * 
>  *
>  * @param input the InputStream to read from
>  * @return the requested byte array
>  * @throws NullPointerException if the input is null
>  * @throws IOException  if an I/O error occurs
>  */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () -> 
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267544#comment-17267544
 ] 

Melloware commented on IO-663:
--

I will see if I am allowed to run one of our servers with a SNAPSHOT release to 
let it burn it.  Like I said its intermittent right now so out of 504 runs a 
week it happens maybe once or twice.  I will let you know what I find out.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (IO-603) Maven dependency version

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed IO-603.
--
Resolution: Fixed

> Maven dependency version
> 
>
> Key: IO-603
> URL: https://issues.apache.org/jira/browse/IO-603
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Ewa Śliwińska
>Priority: Minor
>
> On ["Dependency 
> information"|http://commons.apache.org/proper/commons-io/dependency-info.html]
>  Maven version is *2.7-SNAPSHOT*, but I have troubles downloading this 
> version, also in [Maven 
> repository|https://mvnrepository.com/artifact/commons-io/commons-io] it seems 
> the last version is 2.6.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (IO-626) A mistake in the FilenameUtils.concat()'s Javadoc about an absolute path.

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed IO-626.
--
Fix Version/s: 2.7
   Resolution: Fixed

> A mistake in the FilenameUtils.concat()'s Javadoc about an absolute path.
> -
>
> Key: IO-626
> URL: https://issues.apache.org/jira/browse/IO-626
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Reporter: Yuji Konishi
>Priority: Minor
> Fix For: 2.7
>
>
> Javadoc
> /foo/a/ + ../bar --> foo/bar
> System.out.println(FilenameUtils.concat("/foo/a/", "../bar"));
> /foo/a/ + ../bar --> /foo/bar
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-638) Infinite loop in CharSequenceInputStream.read for 4-byte characters with UTF-8 and 3-byte buffer.

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267534#comment-17267534
 ] 

Gary D. Gregory commented on IO-638:


[~thayne2]

Thank you for your report.

Please feel free to provide a PR on GitHub with a unit test.

 

 

> Infinite loop in CharSequenceInputStream.read for 4-byte characters with 
> UTF-8 and 3-byte buffer.
> -
>
> Key: IO-638
> URL: https://issues.apache.org/jira/browse/IO-638
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thayne McCombs
>Priority: Major
>
> In the constructor of `CharSequenceInputStream` there is the following code 
> to ensure the buffer is large enough to hold one character:
> {code:java}
>  // Ensure that buffer is long enough to hold a complete character   
> final float maxBytesPerChar = encoder.maxBytesPerChar();  
> if (bufferSize < maxBytesPerChar) {
> throw new IllegalArgumentException("Buffer size " + bufferSize + " is 
> less than maxBytesPerChar " +
> maxBytesPerChar);
> }
> {code}
> However, for UTF-8, `maxBytesPerChar` returns 3.0 not 4.0, even though some 
> characters (such as emoji) require 4 bytes to encode.  As a result you can 
> create a `CharSequenceInputStream` with a buffer size of 3, but when 
> attempting to fill the buffer, `CharsetEncoder.encode` will succeed with an 
> OVERFLOW result without actually writing anything to buffer if attempting to 
> encode a 4 byte character. This in turn results in an infinite loop in read 
> methods, since the buffer never actually gets anything written to it.
>  
> NOTE: as I understand it, the reason the encoder returns 3 and not 4 is 
> because 3 is the maximum number of byte that a single java `char` can 
> represent, since a 4 byte encoding in UTF-8 would require two a surragate 
> pair of two `char`s.
>  
> This is may be a problem for other encodings as well, but I've only tested it 
> for utf-8.
>  
> Requiring the buffer to be at least twice the maxBytesPerChar would ensure 
> this doesn't happen.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267532#comment-17267532
 ] 

Gary D. Gregory commented on IO-663:


Git master is different now, may you try again?

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (IO-698) add UnsyncBufferedInputStream and UnsyncBufferedReader and tests

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed IO-698.
--
Resolution: Not A Problem

Closing ticket as the PR is closed since there is no clear performance benefit.

 

> add UnsyncBufferedInputStream and UnsyncBufferedReader and tests
> 
>
> Key: IO-698
> URL: https://issues.apache.org/jira/browse/IO-698
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Streams/Writers
>Reporter: Jin Xu
>Priority: Minor
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> https://github.com/apache/commons-io/pull/184



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IO-695) Exception while there should be none in copyFile

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266659#comment-17266659
 ] 

Gary D. Gregory edited comment on IO-695 at 1/18/21, 8:58 PM:
--

[~morvael]

Please try again with git master as the internals are now different.

Comment here or close the ticket.

TY 


was (Author: garydgregory):
[~morvael]

Please try again with git master as the internals are now different.

 

> Exception while there should be none in copyFile
> 
>
> Key: IO-695
> URL: https://issues.apache.org/jira/browse/IO-695
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Dominik Derwiński
>Priority: Minor
>
> {{public static void copyFile(final File srcFile, final File destFile, final 
> boolean preserveFileDate)}} java doc says: "If the modification operation 
> fails, no indication is provided", yet the method raises an {{IOException}} 
> "Failed setLastModified on ...".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IO-648) Implement directory content equality

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-648:
---
Description: 
Implement directory content equality in org.apache.commons.io.file.PathUtils:

- directoryAndFileContentEquals(Path, Path)
- directoryAndFileContentEquals(Path, Path, LinkOption[], OpenOption[], 
FileVisitOption[])
- directoryContentEquals(Path, Path)
- directoryContentEquals(Path, Path, int, LinkOption[], FileVisitOption[])


  was:
Implement directory content equality in org.apache.commons.io.file.PathUtils:

- {{directoryAndFileContentEquals(...)}}
- {{directoryContentEquals(...)}}



> Implement directory content equality
> 
>
> Key: IO-648
> URL: https://issues.apache.org/jira/browse/IO-648
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.7
>
>
> Implement directory content equality in org.apache.commons.io.file.PathUtils:
> - directoryAndFileContentEquals(Path, Path)
> - directoryAndFileContentEquals(Path, Path, LinkOption[], OpenOption[], 
> FileVisitOption[])
> - directoryContentEquals(Path, Path)
> - directoryContentEquals(Path, Path, int, LinkOption[], FileVisitOption[])



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (IO-648) Implement directory content equality

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed IO-648.
--
Fix Version/s: 2.7
   Resolution: Fixed

> Implement directory content equality
> 
>
> Key: IO-648
> URL: https://issues.apache.org/jira/browse/IO-648
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.7
>
>
> Implement directory content equality in org.apache.commons.io.file.PathUtils:
> - {{directoryAndFileContentEquals(...)}}
> - {{directoryContentEquals(...)}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IO-648) Implement directory content equality

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-648:
---
Description: 
Implement directory content equality in org.apache.commons.io.file.PathUtils:

- {{directoryAndFileContentEquals(*)}}
- {{directoryContentEquals(*)}}


  was:
Implement directory content equality in org.apache.commons.io.file.PathUtils:
 - {{directoryAndFileContentEquals(Path, Path)}}
 - {{directoryAndFileContentEquals(Path, Path, LinkOption[], OpenOption[], 
FileVisitOption[])}}
 - {{directoryContentEquals(Path, Path)}}
 - {{directoryContentEquals(Path, Path, int, LinkOption[], FileVisitOption[])}}


> Implement directory content equality
> 
>
> Key: IO-648
> URL: https://issues.apache.org/jira/browse/IO-648
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Priority: Major
>
> Implement directory content equality in org.apache.commons.io.file.PathUtils:
> - {{directoryAndFileContentEquals(*)}}
> - {{directoryContentEquals(*)}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IO-648) Implement directory content equality

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-648:
---
Description: 
Implement directory content equality in org.apache.commons.io.file.PathUtils:

- {{directoryAndFileContentEquals(...)}}
- {{directoryContentEquals(...)}}


  was:
Implement directory content equality in org.apache.commons.io.file.PathUtils:

- {{directoryAndFileContentEquals(*)}}
- {{directoryContentEquals(*)}}



> Implement directory content equality
> 
>
> Key: IO-648
> URL: https://issues.apache.org/jira/browse/IO-648
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Priority: Major
>
> Implement directory content equality in org.apache.commons.io.file.PathUtils:
> - {{directoryAndFileContentEquals(...)}}
> - {{directoryContentEquals(...)}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267522#comment-17267522
 ] 

Gary D. Gregory commented on IO-651:


[~jmark]

Feel free to provide a PR on GitHub with unit tests.

 

> Provide method to retrieve data from DeferredFileOutputStream as InputStream
> 
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
>  Labels: easyfix, performance, pull-request-available
>
> It would be very helpful to have to {{toInputStream()}} method on the 
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow 
> for improved efficiency since in the case of in-memory data the byte buffer 
> would not need to be copied (as opposed to the current {{getData()}} method). 
> The implementation is pretty simple and can be something like the following 
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-661) FileUtils throws inconsistent exceptions

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267521#comment-17267521
 ] 

Gary D. Gregory commented on IO-661:


[~haozhong]

Please see the current git master which contains more consistent exceptions. If 
your use case is covered, please close this ticket.

TY.

> FileUtils throws inconsistent exceptions
> 
>
> Key: IO-661
> URL: https://issues.apache.org/jira/browse/IO-661
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.6
>Reporter: Hao Zhong
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The FileUtils throws inconsistent exceptions, when an input is not a 
> directory. 
> The copyFileToDirectory throws IllegalArgumentException:
>  
> {code:java}
>   public static void copyFileToDirectory(final File srcFile, final File 
> destDir, final boolean preserveFileDate)
> throws IOException {
> if (destDir == null) {
> throw new NullPointerException("Destination must not be null");
> }
> if (destDir.exists() && destDir.isDirectory() == false) {
> throw new IllegalArgumentException("Destination '" + destDir + "' 
> is not a directory");
> }
> final File destFile = new File(destDir, srcFile.getName());
> copyFile(srcFile, destFile, preserveFileDate);
> }
> {code}
> The other methods throw IOException:
>  
>  
> {code:java}
>  public static void moveFileToDirectory(final File srcFile, final File 
> destDir, final boolean createDestDir)
> throws IOException {
> validateMoveParameters(srcFile, destDir);
> if (!destDir.exists() && createDestDir) {
> destDir.mkdirs();
> }
> if (!destDir.exists()) {
> throw new FileNotFoundException("Destination directory '" + 
> destDir +
> "' does not exist [createDestDir=" + createDestDir + "]");
> }
> if (!destDir.isDirectory()) {
> throw new IOException("Destination '" + destDir + "' is not a 
> directory");
> }
> moveFile(srcFile, new File(destDir, srcFile.getName()));
> }
> {code}
> I feel that IOException is more reasonable. Although the messages are the 
> same, the different exception can cause problems when programmers catch the 
> thrown exceptions. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (IO-685) LineReader to implement AutoCloseable

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved IO-685.

Fix Version/s: (was: 3.x)
   Resolution: Fixed

[~andrear]

I am marking this ticket as resolved as {{LineIterator}} implements 
{{Closable}}.

Please verify git master for your use case and close this ticket if all is well 
for you.

 

> LineReader to implement AutoCloseable
> -
>
> Key: IO-685
> URL: https://issues.apache.org/jira/browse/IO-685
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.7
>Reporter: Andrea Rombaldi
>Priority: Minor
> Fix For: 2.9.0
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> org.apache.commons.io.LineReader should implement the AutoCloseable interface 
> in order to allow the use of try-with-resources statement such as in the 
> following example:
> {{try (final LineIterator itr = new LineIterator(new 
> FileReader("c:/temp/readme.txt"))) {}}
>  {{  while (itr.hasNext()) {}}
>  {{    System.out.println(itr.next());}}
>     }
> }
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267516#comment-17267516
 ] 

Gary D. Gregory edited comment on IO-686 at 1/18/21, 8:40 PM:
--

[~themoffster]

This is related to [IO=690], the underlying code in git master is now back to 
an NPE (with a better message) for null input; the Javadoc is improved as well.

Please review git master, comment nad/or close this ticket if appropriate.

 


was (Author: garydgregory):
[~themoffster]

This is related to [IO=690], the underlying code in git master is now back to 
an NPE (with a better message) for null input; the Javadoc is improved as well.

 

> IOUtils.toByteArray(InputStream) Javadoc does not match code
> 
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method 
> should throw an exception, however it is producing an empty byte array 
> instead.
> {code:java}
> /**
>  * Gets the contents of an InputStream as a byte[].
>  * 
>  * This method buffers the input internally, so there is no need to use a
>  * BufferedInputStream.
>  * 
>  *
>  * @param input the InputStream to read from
>  * @return the requested byte array
>  * @throws NullPointerException if the input is null
>  * @throws IOException  if an I/O error occurs
>  */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () -> 
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267516#comment-17267516
 ] 

Gary D. Gregory commented on IO-686:


[~themoffster]

This is related to [IO=690], the underlying code in git master is now back to 
an NPE (with a better message) for null input; the Javadoc is improved as well.

 

> IOUtils.toByteArray(InputStream) Javadoc does not match code
> 
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method 
> should throw an exception, however it is producing an empty byte array 
> instead.
> {code:java}
> /**
>  * Gets the contents of an InputStream as a byte[].
>  * 
>  * This method buffers the input internally, so there is no need to use a
>  * BufferedInputStream.
>  * 
>  *
>  * @param input the InputStream to read from
>  * @return the requested byte array
>  * @throws NullPointerException if the input is null
>  * @throws IOException  if an I/O error occurs
>  */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () -> 
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-net] arturobernalg opened a new pull request #72: Minor Improvement:

[GitBox]

arturobernalg opened a new pull request #72:
URL: https://github.com/apache/commons-net/pull/72


   * Add final
   * Use Empty array
   * Remove Unused import
   * Use Integer.parseInt
   * Replace String in loop by StringBuilder
   * Remove redundant initializer



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (IO-690) IOUtils.toByteArray(null) no longer throws a NullPointerException

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved IO-690.

Fix Version/s: 2.9.0
   Resolution: Fixed

In git master, please verify and close this ticket.

 

> IOUtils.toByteArray(null) no longer throws a NullPointerException
> -
>
> Key: IO-690
> URL: https://issues.apache.org/jira/browse/IO-690
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Chris Heisterkamp
>Assignee: Gary D. Gregory
>Priority: Minor
> Fix For: 2.9.0
>
>
> The javadoc for IOUtils.toByteArray still says
> {{Throws:}}
> {{ NullPointerException - if the input is null}}
>  
> but in 2.8.0 it returns an empty byte[] instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IO-690) IOUtils.toByteArray(null) no longer throws a NullPointerException

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated IO-690:
---
Assignee: Gary D. Gregory

> IOUtils.toByteArray(null) no longer throws a NullPointerException
> -
>
> Key: IO-690
> URL: https://issues.apache.org/jira/browse/IO-690
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Chris Heisterkamp
>Assignee: Gary D. Gregory
>Priority: Minor
>
> The javadoc for IOUtils.toByteArray still says
> {{Throws:}}
> {{ NullPointerException - if the input is null}}
>  
> but in 2.8.0 it returns an empty byte[] instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IO-703) FileUtils.directoryContains shall throw NullPointerException for null inputs

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266592#comment-17266592
 ] 

Gary D. Gregory edited comment on IO-703 at 1/18/21, 6:07 PM:
--

[~haozhong]

Please see git master and either comment further or close this ticket if the 
Javadoc and behavior match your use case.

 


was (Author: garydgregory):
Please see git master.

> FileUtils.directoryContains shall throw NullPointerException for null inputs
> 
>
> Key: IO-703
> URL: https://issues.apache.org/jira/browse/IO-703
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Hao Zhong
>Priority: Major
>
> The code of this method is as follows:
> {code:java}
>  public static boolean directoryContains(final File directory, final File 
> child) throws IOException {// Fail fast against NullPointerException
> if (directory == null) {
> throw new IllegalArgumentException("Directory must not be null");
> }if (!directory.isDirectory()) {
> throw new IllegalArgumentException("Not a directory: " + 
> directory);
> }
>...
> }{code}
> When directory is null, it throws IllegalArgumentException, but all the other 
> methods of this class throw NullPointerException:
>  
> {code:java}
>public static void copyToDirectory(final File src, final File destDir) 
> throws IOException {
> if (src == null) {
> throw new NullPointerException("Source must not be null");
> }
>  
> }{code}
>  
> {code:java}
> private static void checkFileRequirements(final File src, final File dest) 
> throws FileNotFoundException {
> if (src == null) {
> throw new NullPointerException("Source must not be null");
> }
> if (dest == null) {
> throw new NullPointerException("Destination must not be null");
> }
> if (!src.exists()) {
> throw new FileNotFoundException("Source '" + src + "' does not 
> exist");
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-vfs] garydgregory commented on pull request #154: Rework SoftRefFilesCache locking

[GitBox]

garydgregory commented on pull request #154:
URL: https://github.com/apache/commons-vfs/pull/154#issuecomment-762399913


   @ecki , @rgoers, any thoughts?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] asfgit merged pull request #80: Minor Improvement:

[GitBox]

asfgit merged pull request #80:
URL: https://github.com/apache/commons-rng/pull/80


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] coveralls edited a comment on pull request #80: Minor Improvement:

[GitBox]

coveralls edited a comment on pull request #80:
URL: https://github.com/apache/commons-rng/pull/80#issuecomment-762208005


   
   [![Coverage 
Status](https://coveralls.io/builds/36408460/badge)](https://coveralls.io/builds/36408460)
   
   Coverage decreased (-0.0001%) to 99.508% when pulling 
**881650c63cbeefa8ba7d2f9404cf8be5de1c6e25 on 
arturobernalg:feature/feature/minor_improvement** into 
**b9f778cbf25dc4f21fb6454392424ccf7276cdeb on apache:master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] aherbert commented on pull request #81: Minor Improvement:

[GitBox]

aherbert commented on pull request #81:
URL: https://github.com/apache/commons-rng/pull/81#issuecomment-762378135


   Since we use automated checking tools to ensure that parameters are 
effectively final then I see the use of the final keyword as noise. This is 
very true for short methods which make up the majority of this code base. I 
tend to agree with the user who posted on your KISS article as a counter 
argument for using final. This should be raised as a discussion and/or vote on 
the dev mailing list before committing.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (NET-697) problem while transferring an Ascii file containing COMP-3 values from Windows to Z\os

[Itay Itzhak (Jira)]

[ 
https://issues.apache.org/jira/browse/NET-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267396#comment-17267396
 ] 

Itay Itzhak commented on NET-697:
-

Hi [~ggregory],

Same results with commons-net-3.7.2

 

Regards,

Itay

> problem while transferring an Ascii file containing COMP-3 values from 
> Windows to Z\os
> --
>
> Key: NET-697
> URL: https://issues.apache.org/jira/browse/NET-697
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Reporter: Itay Itzhak
>Priority: Major
>
> For instance, consider a file with only 1 record x’4D320A0C0D0A’ 6 bytes: “M” 
> + “2” + x’0A0C’ (COMP-3 x’250C’) + x’0D0A’ (indicator for end of record) 
>  
> We expect to receive only one record EBCDIC x’D4F2250C’ but instead I get two 
> records since x’0A’ is converted to x’25’ which is EBCDIC newline character 
> (LF) 
>  
> Record 1: X’D4F2’ 
> Record 2: x’0C’ 
>  
> In Windows, the delimiter is X’0D0A’. As a matter of fact, when I transfer 
> the exact same file using Windows FTP, then I get the expected result which 
> is a single record with EBCDIC x’D4F2250C’



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-vfs] garydgregory merged pull request #155: FileContentThreadData: lazy ArrayList initialization to save memory

[GitBox]

garydgregory merged pull request #155:
URL: https://github.com/apache/commons-vfs/pull/155


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-email] arturobernalg opened a new pull request #36: Minor Improvement:

[GitBox]

arturobernalg opened a new pull request #36:
URL: https://github.com/apache/commons-email/pull/36


   * Add final
   * Use Standard Charset object
   * Change 'StringBuffer' by  'StringBuilder'
   * Use Empty array
   * Use try resource



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] garydgregory commented on pull request #81: Minor Improvement:

[GitBox]

garydgregory commented on pull request #81:
URL: https://github.com/apache/commons-rng/pull/81#issuecomment-762273653


   Each component has it's own rule but in general, I prefer to see "final" so
   I don't have to think about looking for a reassignment when I look at a
   longer method. See
   https://garygregory.wordpress.com/2013/01/26/the-final-kiss-in-java/
   
   Gary
   
   On Mon, Jan 18, 2021, 08:28 Alex Herbert  wrote:
   
   > The change to use final method arguments is a style change. We already use
   > code style checks using the PMD rule AvoidReassigningParameters to ensure
   > method arguments are effectively final. The gratuitous use of final does
   > not add functionality to the code and in keeping with the source code for
   > the JDK we have chosen not to add final in front of everything in the
   > source.
   >
   > Also note that using an IDE to refactor all the code to add final has now
   > broken code style formatting (see checkstyle failures on Travis) due to
   > line length changes.
   >
   > I would remove all the use of final from all method arguments as this is
   > already enforced by build checks. Then it is easy to see in the PR what is
   > left to make final as local or instance variables.
   >
   > —
   > You are receiving this because you are subscribed to this thread.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] aherbert commented on pull request #81: Minor Improvement:

[GitBox]

aherbert commented on pull request #81:
URL: https://github.com/apache/commons-rng/pull/81#issuecomment-762250958


   The change to use final method arguments is a style change. We already use 
code style checks using the PMD rule `AvoidReassigningParameters` to ensure 
method arguments are effectively final. The gratuitous use of final does not 
add functionality to the code and in keeping with the source code for the JDK 
we have chosen not to add final in front of everything in the source.
   
   Also note that using an IDE to refactor all the code to add final has now 
broken code style formatting (see checkstyle failures on Travis) due to line 
length changes.
   
   I would remove all the use of final from all method arguments as this is 
already enforced by build checks. Then it is easy to see in the PR what is left 
to make final as local or instance variables.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] arturobernalg commented on a change in pull request #80: Minor Improvement:

[GitBox]

arturobernalg commented on a change in pull request #80:
URL: https://github.com/apache/commons-rng/pull/80#discussion_r559562830



##
File path: 
commons-rng-simple/src/main/java/org/apache/commons/rng/simple/ThreadLocalRandomSource.java
##
@@ -69,7 +69,7 @@
  *
  * This should only be modified to create new instances in a 
synchronized block.
  */
-private static EnumMap> 
sources =
+private static final EnumMap> sources =

Review comment:
   Changed 





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (IO-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved IO-693.

Fix Version/s: 2.9.0
   Resolution: Fixed

> FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
> --
>
> Key: IO-693
> URL: https://issues.apache.org/jira/browse/IO-693
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Robert Seidel
>Priority: Major
> Fix For: 2.9.0
>
>
> # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory 
> has changed. Now nio is used instead of the old File.delete. The problem is, 
> nio does not delete files with read only attribute and failes instead.
>  # The interface of FileUtils was not extended to provide the possibility to 
> use a DeleteOption, so I guess, if someone wants to remove "all" files, then 
> PathUtils should be used. But here comes the next problem, 
> FileUtils.deleteDirectory checks for the existence (in opposite to its 
> javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-rng] aherbert commented on a change in pull request #80: Minor Improvement:

[GitBox]

aherbert commented on a change in pull request #80:
URL: https://github.com/apache/commons-rng/pull/80#discussion_r559559941



##
File path: 
commons-rng-simple/src/main/java/org/apache/commons/rng/simple/ThreadLocalRandomSource.java
##
@@ -69,7 +69,7 @@
  *
  * This should only be modified to create new instances in a 
synchronized block.
  */
-private static EnumMap> 
sources =
+private static final EnumMap> sources =

Review comment:
   This now fails checkstyle naming conventions. Please rename to SOURCES.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] aherbert commented on a change in pull request #80: Minor Improvement:

[GitBox]

aherbert commented on a change in pull request #80:
URL: https://github.com/apache/commons-rng/pull/80#discussion_r559559941



##
File path: 
commons-rng-simple/src/main/java/org/apache/commons/rng/simple/ThreadLocalRandomSource.java
##
@@ -69,7 +69,7 @@
  *
  * This should only be modified to create new instances in a 
synchronized block.
  */
-private static EnumMap> 
sources =
+private static final EnumMap> sources =

Review comment:
   This now fails checkstyle naming convensions. Please rename to SOURCES.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-vfs] MaxKellermann commented on pull request #154: Rework SoftRefFilesCache locking

[GitBox]

MaxKellermann commented on pull request #154:
URL: https://github.com/apache/commons-vfs/pull/154#issuecomment-762236081


   Rebased and fixed conflict because the meanwhile-merged commit 
048d34d1e0de11c1ecf44efcae58a225cee1ea96 duplicates my commit 
"SoftRefFilesCache: remove unnecessary initializer" which I authored after it 
was requested by @garydgregory ... which has now turned out to be a waste of 
time, because somebody else's version authored after mine was merged instead.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-vfs] MaxKellermann commented on pull request #155: FileContentThreadData: lazy ArrayList initialization to save memory

[GitBox]

MaxKellermann commented on pull request #155:
URL: https://github.com/apache/commons-vfs/pull/155#issuecomment-762233501


   Rebased (and fixed conflicts).



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] coveralls commented on pull request #81: Minor Improvement:

[GitBox]

coveralls commented on pull request #81:
URL: https://github.com/apache/commons-rng/pull/81#issuecomment-762227569


   
   [![Coverage 
Status](https://coveralls.io/builds/36401313/badge)](https://coveralls.io/builds/36401313)
   
   Coverage remained the same at 99.508% when pulling 
**cc8cd5cc0397080ecebedd12129384327cf20a79 on 
arturobernalg:feature/feature/minor_improvement2** into 
**b9f778cbf25dc4f21fb6454392424ccf7276cdeb on apache:master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] coveralls commented on pull request #80: Minor Improvement:

[GitBox]

coveralls commented on pull request #80:
URL: https://github.com/apache/commons-rng/pull/80#issuecomment-762208005


   
   [![Coverage 
Status](https://coveralls.io/builds/36400399/badge)](https://coveralls.io/builds/36400399)
   
   Coverage decreased (-0.0001%) to 99.508% when pulling 
**0a7891093683eaf3b560cabca675f9735003d9fd on 
arturobernalg:feature/feature/minor_improvement** into 
**b9f778cbf25dc4f21fb6454392424ccf7276cdeb on apache:master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (IO-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently

[Robert Seidel (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267153#comment-17267153
 ] 

Robert Seidel commented on IO-693:
--

Yup, it can be closed.

> FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
> --
>
> Key: IO-693
> URL: https://issues.apache.org/jira/browse/IO-693
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Robert Seidel
>Priority: Major
>
> # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory 
> has changed. Now nio is used instead of the old File.delete. The problem is, 
> nio does not delete files with read only attribute and failes instead.
>  # The interface of FileUtils was not extended to provide the possibility to 
> use a DeleteOption, so I guess, if someone wants to remove "all" files, then 
> PathUtils should be used. But here comes the next problem, 
> FileUtils.deleteDirectory checks for the existence (in opposite to its 
> javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-text] kinow closed pull request #197: Bump mockito-inline from 3.7.0 to 3.7.7

[GitBox]

kinow closed pull request #197:
URL: https://github.com/apache/commons-text/pull/197


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-text] dependabot[bot] commented on pull request #197: Bump mockito-inline from 3.7.0 to 3.7.7

[GitBox]

dependabot[bot] commented on pull request #197:
URL: https://github.com/apache/commons-text/pull/197#issuecomment-762137412


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] arturobernalg opened a new pull request #81: Minor Improvement:

[GitBox]

arturobernalg opened a new pull request #81:
URL: https://github.com/apache/commons-rng/pull/81


   * Using final parameters
   * Using final local variables
   * Using final for instance variable
   
   Intend to make the code more simple and read-only using final 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] coveralls commented on pull request #697: Bump junit-pioneer from 1.1.0 to 1.2.0

[GitBox]

coveralls commented on pull request #697:
URL: https://github.com/apache/commons-lang/pull/697#issuecomment-762095648


   
   [![Coverage 
Status](https://coveralls.io/builds/36394966/badge)](https://coveralls.io/builds/36394966)
   
   Coverage remained the same at 94.981% when pulling 
**50542351ae350653cee5e893eb5f3bf3f07b7a21 on 
dependabot/maven/org.junit-pioneer-junit-pioneer-1.2.0** into 
**0b135af5a0553d9882efef13e60a464986e6af36 on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-rng] arturobernalg opened a new pull request #80: Minor Improvement:

[GitBox]

arturobernalg opened a new pull request #80:
URL: https://github.com/apache/commons-rng/pull/80


   * Add final on private variable
   * fix javadoc
   * Use Array Filling



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-csv] coveralls commented on pull request #129: Bump mockito-core from 3.7.0 to 3.7.7

[GitBox]

coveralls commented on pull request #129:
URL: https://github.com/apache/commons-csv/pull/129#issuecomment-762094909


   
   [![Coverage 
Status](https://coveralls.io/builds/36394987/badge)](https://coveralls.io/builds/36394987)
   
   Coverage remained the same at 98.454% when pulling 
**cce149a6327439eb5c1827060a8493e03d5ed8bb on 
dependabot/maven/org.mockito-mockito-core-3.7.7** into 
**bf2f8093a49a3432be62e9fdae073e82ac78bd04 on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-dbutils] coveralls commented on pull request #54: Bump mockito-core from 3.7.0 to 3.7.7

[GitBox]

coveralls commented on pull request #54:
URL: https://github.com/apache/commons-dbutils/pull/54#issuecomment-762093153


   
   [![Coverage 
Status](https://coveralls.io/builds/36394884/badge)](https://coveralls.io/builds/36394884)
   
   Coverage remained the same at 65.619% when pulling 
**bb696e628b03c27fc0e4708f29caa0496ab9fc5b on 
dependabot/maven/org.mockito-mockito-core-3.7.7** into 
**453f2fc7bbbd8477c421b446e66be9e80fe9b045 on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-text] coveralls commented on pull request #197: Bump mockito-inline from 3.7.0 to 3.7.7

[GitBox]

coveralls commented on pull request #197:
URL: https://github.com/apache/commons-text/pull/197#issuecomment-762091569


   
   [![Coverage 
Status](https://coveralls.io/builds/36394818/badge)](https://coveralls.io/builds/36394818)
   
   Coverage remained the same at 98.682% when pulling 
**b7497e4dd6a7ea2e4f08d1032d7bb5977afa20b0 on 
dependabot/maven/org.mockito-mockito-inline-3.7.7** into 
**65a4f25433a69a6457e5e9b9b390843a6d032b51 on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org