Re: [IO] IO-855 PeekableInputStream?

PING! On 2024/04/29 12:27:10 Gary Gregory wrote: > RE https://issues.apache.org/jira/browse/IO-855 > > There are zero tests or usage in IO for PeekableInputStream. > > Could the original author add some? > > Why does PeekableInputStream extend CircularBufferInputStream instead > of BufferedInpu

Re: [IO] Change in behavior in Commons FileUpload after upgrade to Commons IO 2.16.1

Stephan, Thank you for your message. This is more of a design deffect IMO,. If there is a desire for disabling a feature like caching then there should be a toggle for that, not relying on a side effect of a magic number. PRs welcome! :-) Gary On Wed, Apr 10, 2024, 9:24 AM Stephan Markwalder

Re: [IO-842] Deprecate more or undeprecate non-Charset methods

Except in Java 18 we do need it, for two independent reasons: 1. UTF-8 is still not the guaranteed, runtime character set that the various methods will use. JDKs can be configured to use a different default character set. Bugs from incorrect default character set will now be even harder to find si

Re: [IO-842] Deprecate more or undeprecate non-Charset methods

I think we should remove the deprecations and add more explicit Javadocs that spell out that there are oddities with the defaultCharset() depending upon the operating system. Note this problem has been in existence since Java 1.4, and we did nothing about it for a considerable amount of time. Pl

Re: [IO][ALL?] PRs should NOT deploy snapshots

TY Sebb! Gary On Sun, Dec 24, 2023 at 11:18 AM sebb wrote: > > Oops; fixed > > On Sun, 24 Dec 2023 at 15:49, Gary Gregory wrote: > > > > It seems that [IO] tries and fails to deploy snapshots for PRs. That > > should not happen, the deploying, that is. > > > > PR log: > > ... > > [INFO] --- mav

Re: [IO][ALL?] PRs should NOT deploy snapshots

Oops; fixed On Sun, 24 Dec 2023 at 15:49, Gary Gregory wrote: > > It seems that [IO] tries and fails to deploy snapshots for PRs. That > should not happen, the deploying, that is. > > PR log: > ... > [INFO] --- maven-deploy-plugin:3.1.1:deploy (default-deploy) @ commons-io --- > 189[INFO] >

RE: Re: [IO] Suggestion for AbstractFileComparator

Sorry to barge in, several things here: I love the JDK. At the very least, you could say, that 'IllegalStateException' is the appropriate name in this case, as it purveys the fact, that the results might fail to fulfill the contract. UncheckedIoException doesn't do that. Pretty subtle! ;-)  I

Re: [IO] Suggestion for AbstractFileComparator

On Sat, Dec 2, 2023 at 12:01 AM Miguel Muñoz wrote: > > @Elliotte Rusty Harold, > I'd like to make two unrelated points. > 1. I wasn't suggesting the missingFilesFirst() or missingFilesLast() methods > as a solution to the issues raised in IO-813 LastModifiedFileComparator > should not throw exc

Re: [IO] Suggestion for AbstractFileComparator

@Elliotte Rusty Harold, ​I'd like to make two unrelated points. ​ ​1. I wasn't suggesting the missingFilesFirst() or missingFilesLast() methods as a solution to the issues raised in IO-813 LastModifiedFileComparator should not throw exceptions, period. I just thought these met

Re: [IO] Suggestion for AbstractFileComparator

I'm not sure we need two methods here, or even one. We simply need to detect a missing file and assign it a time like Integer.MIN_INT. Make the behavior as reproducible as reasonable for the case where the file doesn't exist and never existed. For cases where the last modified time changes or a fi

Re: [IO] Suggestion for AbstractFileComparator

Good question. Since the missingFilesFirst/Last() methods would most likely be ​used for sorting, I'm going to ​assume ​your "ls -type" command sorts the ​files at ​some point. I'll assume it's by last-modified, to put more ​recent files first. ​ ​Without calling the missingFile

Re: [IO] Suggestion for AbstractFileComparator

Hi Miguel, I like the idea but I think we need a use case, even if it's one we can only write about here, otherwise we are making everything more complicated. For example, if implementing an "ls"-type, command, a UI, or an app configuration, what would be best for a user? Let's say some files di

Re: [IO] Bug in FileChannels.contentEquals?

A PR with a test for FileChannels.contentEquals is available here: https://github.com/apache/commons-io/pull/509 On Mon, Nov 6, 2023 at 5:37 PM Elliotte Rusty Harold wrote: > Can you turn this into a PR against HEAD that adds a unit test that > fails? That would be fairly conclusive proof. It's

Re: [IO] Bug in FileChannels.contentEquals?

Can you turn this into a PR against HEAD that adds a unit test that fails? That would be fairly conclusive proof. It's better if you don't send a fix, at least at first. That makes it easier to verify the bug. On Mon, Nov 6, 2023 at 10:04 AM Stephan Markwalder wrote: > > Hi, > > I think I have fo

Re: [IO] checking in on PR - "adds new method to query the host OS for the temp directory path #500"

Patience! ;-) Gary On Wed, Oct 18, 2023, 12:46 PM David wrote: > hihi friends - my team encountered an issue with how java reports the > system temp directory that nerfed up the ability of our app to run properly > on some OS hosts. We fixed the problem on our end and backported the change > t

Re: [IO] Unintuitive behavior in BoundedInputStream.onMaxLength

Better documentation is quite reasonable :-) feel free to submit a PR Thank you! Gary On Tue, Aug 15, 2023, 10:13 AM James Reeves wrote: > I was looking into a bug in FileUpload 2.0.0-M1 and tracked it down to a > misuse of BoundedInputStream.onMaxLength. The reason I'm sending this email > bef

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On my end, I'll make sure IO filters can interoperate with PathMatchers if they don't already... Gary On Thu, Jun 29, 2023, 09:10 Elliotte Rusty Harold wrote: > On Thu, Jun 29, 2023 at 8:12 AM Gary Gregory > wrote: > > > > On Thu, Jun 29, 2023 at 7:20 AM Elliotte Rusty Harold > > wrote: > >

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On Thu, Jun 29, 2023 at 8:12 AM Gary Gregory wrote: > > On Thu, Jun 29, 2023 at 7:20 AM Elliotte Rusty Harold > wrote: > I'm not sure what you are proposing. Adding a new filter to IO that > behaves like Ant? Adding a new filter to IO that behaves like Python? > Are Ant and Python expressions _e

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

It is common pattern called globstar, eg from https://en.wikipedia.org/wiki/Glob_(programming): globstar: allows ** on its own as a name component to recursively match any number of layers of non-hidden directories.[10] Also supported by the JS libraries and Python's glob. so it is not only an An

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On Thu, Jun 29, 2023 at 7:20 AM Elliotte Rusty Harold wrote: > > On Mon, Jun 19, 2023 at 8:17 PM Gary Gregory wrote: > > > I like the general idea of adding configurable include and exclude features. > > > > I am uncertain about baking in the Ant-specific pattern formats in > > Commons IO. Allowi

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On Mon, Jun 19, 2023 at 8:17 PM Gary Gregory wrote: > I like the general idea of adding configurable include and exclude features. > > I am uncertain about baking in the Ant-specific pattern formats in > Commons IO. Allowing the include and exclude feature to be provided > through some interfaces

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

So... I'll leave you to it then ;-) Gary On Tue, Jun 27, 2023, 10:04 Elliotte Rusty Harold wrote: > On Tue, Jun 27, 2023 at 9:22 AM Gary Gregory > wrote: > > > > I think that we are close to what Ant needs > > with org.apache.commons.io.filefilter.WildcardFileFilter. Perhaps Ant > > should jus

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On Tue, Jun 27, 2023 at 9:22 AM Gary Gregory wrote: > > I think that we are close to what Ant needs > with org.apache.commons.io.filefilter.WildcardFileFilter. Perhaps Ant > should just implement its own "AntWildcardFileFilter" as a copy or subclass > of WildcardFileFilter. > > Or, are you thinkin

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

I think that we are close to what Ant needs with org.apache.commons.io.filefilter.WildcardFileFilter. Perhaps Ant should just implement its own "AntWildcardFileFilter" as a copy or subclass of WildcardFileFilter. Or, are you thinking that WildcardFileFilter should have a new toggle "star star matc

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

On Mon, Jun 19, 2023 at 8:17 PM Gary Gregory wrote: > > I like the general idea of adding configurable include and exclude features. > > I am uncertain about baking in the Ant-specific pattern formats in > Commons IO. Allowing the include and exclude feature to be provided > through some interface

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

I think you could achieve what you want today using the existing PathFilter hierarchy plus a custom Ant PathFilter. WDYT? Gary On Mon, Jun 19, 2023, 20:17 Gary Gregory wrote: > Hi Elliotte, > > On Mon, Jun 19, 2023 at 4:08 PM Elliotte Rusty Harold > wrote: > > > > I'm working on a longterm pr

Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes

Hi Elliotte, On Mon, Jun 19, 2023 at 4:08 PM Elliotte Rusty Harold wrote: > > I'm working on a longterm project to remove a lot of duplicate code > and assorted dependencies from Apache Maven by migrating many of our > utilities to Apache Commons equivalents or near-equivalents. In > particular I

Re: [IO] Commons IOIO-552 FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with '~' (tilde)

That sounds like a good approach, and is one that I've taken before on other classes. But I want to be clear about something. Are you thinking of private builders that are invoked by static methods? This would mean the API wouldn't change much. Or were you thinking of having the user inst

Re: [IO] Commons IOIO-552 FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with '~' (tilde)

Neither approach is what I'd prefer. Instead I see a new class with a builder to let you choose whether or not shell substitution to takes place and whatever other setting (maybe case sensitivity for example) SomeNewClass.builder() .setShellSubstitution(true) // replace ~ .build() .someFu

Re: [IO] 2 Patches for SymbolicLinkFileFilter

This should likely be one PR, see comments in the PR. In general, when you submit a fix in a PR, it should contain changes to both main and test. The test changed or added to the test folder should fail without the changes to main. Gary On Wed, Apr 19, 2023, 01:30 Miguel Muñoz wrote: > Today I

Re: [IO] 2 Patches for SymbolicLinkFileFilter

Today I resubmitted both changes as Pull Requests. — Miguel Muñoz On Tue, Apr 18, 2023 at 3:44 AM Gary Gregory wrote: > Thanks Miguel, > > Please provide changes as PRs on GiHub. This is the best way to go IMO > because it runs code against all tests on all configured OSs and Java > versions, a

Re: [IO] IO-769: FileUtils copyDirectory() should not use COPY_ATTRIBUTES #377

Merged https://github.com/apache/commons-io/pull/377, see the PR for behavior. For the upcoming 2.12.0, COPY_ATTRIBUTES is no longer used by default. Gary On 2023/04/17 12:27:09 Gary Gregory wrote: > Hi All, > > I would like to get some ideas and consensus on how to proceed with > https://githu

Re: [IO] 2 Patches for SymbolicLinkFileFilter

Thanks Miguel, Please provide changes as PRs on GiHub. This is the best way to go IMO because it runs code against all tests on all configured OSs and Java versions, and provides the least friction for managing changes. TY! Gary On Tue, Apr 18, 2023, 04:20 Miguel Muñoz wrote: > Developers, > >

Re: [IO] 2 Patches for SymbolicLinkFileFilter

> > Or as a Github PR: > +1 On Tue, 18 Apr 2023 at 11:18, sebb wrote: > Or as a Github PR: > > https://github.com/apache/commons-io/pulls > > These systems are easier for developers to track than emails, which > can get overlooked. > > On Tue, 18 Apr 2023 at 09:54, Gilles Sadowski > wrote: > >

Re: [IO] 2 Patches for SymbolicLinkFileFilter

Or as a Github PR: https://github.com/apache/commons-io/pulls These systems are easier for developers to track than emails, which can get overlooked. On Tue, 18 Apr 2023 at 09:54, Gilles Sadowski wrote: > > Hi. > > Le mar. 18 avr. 2023 à 10:20, Miguel Muñoz a écrit : > > > > Developers, > > >

Re: [IO] 2 Patches for SymbolicLinkFileFilter

Hi. Le mar. 18 avr. 2023 à 10:20, Miguel Muñoz a écrit : > > Developers, > > (I'm new to Apache, Welcome. > so I hope this is the right way to submit patches.) The usual way would be to file a report on the bug-tracking system: https://issues.apache.org/jira/projects/IO and upload patches th

Re: [IO] SymbolicLinkFileFilter

"The class per its javadoc filters for symbolic links on files." It sounds like it's only supposed to pass files that are symbolic links. If that's the idea, the class doesn't work at all. If not, we need a clearer description. As for unit tests, maybe the test should detect the Windows OS and ju

Re: [IO] SymbolicLinkFileFilter

Here's a better idea for how to write the unit test. First, we put something in the SymbolicLinkFileFilter class like this: public class SymbolicLinkFileFilter { private static LinkTester linkTester = new LinkTester(); // defined below static setLinkTesterForUnitTests(LinkTester unitTestLinkT

Re: [IO] SymbolicLinkFileFilter

Hi Miguel, Thank you for reviewing. A better unit test would help of course ;-) but testing links can be a pain as the JVM requires admin rights on Windows 10 at least. This might not be an issue for GitHub but be aware of it if you run builds locally. The class per its javadoc filters for symbol

Re: IO-753

. Oktober 2021 18:29 An: dev@commons.apache.org Betreff: Re: IO-753 Just a warning about threads: if this is to be used in Java EE, you are not allowed to spawn your own threads. It would be better if the API can accept an Executor or ExecutorService. That way, JEE applications can provide a

Re: IO-753

Utils.copy methods it would just be a shorthand for a rather simple implementation. But one that the user can rely on to work probably better than their own implementation. -Ursprüngliche Nachricht- Von: Rob Spoor Gesendet: Samstag, 9. Oktober 2021 12:40 An: dev@commons.apache.org Betreff:

Re: IO-753

rüngliche Nachricht- > Von: Rob Spoor > Gesendet: Samstag, 9. Oktober 2021 12:40 > An: dev@commons.apache.org > Betreff: Re: IO-753 > > Isn't this already possible with PipedOutputStream and PipedOutputStream? > > PipedInputStream inputStream = new Pip

Re: IO-753

: Re: IO-753 Isn't this already possible with PipedOutputStream and PipedOutputStream? PipedInputStream inputStream = new PipedInputStream(size); PipedOutputStream outputStream = new PipedOutputStream(inputStream); Any write to outputStream is now visible in inputStream. Note tha

Re: IO-753

Isn't this already possible with PipedOutputStream and PipedOutputStream? PipedInputStream inputStream = new PipedInputStream(size); PipedOutputStream outputStream = new PipedOutputStream(inputStream); Any write to outputStream is now visible in inputStream. Note that the writing and re

Re: [IO] release soon

It's not, I am talking about a different regression. The OSGi header issue is new. Gary On Mon, Jun 7, 2021 at 9:12 AM Jean-Baptiste Onofre wrote: > > By the way, I saw IO-733, but it was not obvious to me it was related to OSGi > headers ;) > > > Le 7 juin 2021 à 15:04, Gary Gregory a écrit

Re: [IO] release soon

By the way, I saw IO-733, but it was not obvious to me it was related to OSGi headers ;) > Le 7 juin 2021 à 15:04, Gary Gregory a écrit : > > Please search Jira before you create duplicate issues. > > Gary > > On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre wrote: > >> Hi, >> >> I created

Re: [IO] release soon

Sorry about that, let me remove this Jira. Regards JB > Le 7 juin 2021 à 15:04, Gary Gregory a écrit : > > Please search Jira before you create duplicate issues. > > Gary > > On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre wrote: > >> Hi, >> >> I created https://issues.apache.org/jira/brow

Re: [IO] release soon

Please search Jira before you create duplicate issues. Gary On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre wrote: > Hi, > > I created https://issues.apache.org/jira/browse/IO-738 < > https://issues.apache.org/jira/browse/IO-738> about OSGi headers. > > I’m working on a PR to fix the headers. >

Re: [IO] release soon

Hi, I created https://issues.apache.org/jira/browse/IO-738 about OSGi headers. I’m working on a PR to fix the headers. Would it be possible to include in 2.10.0 ? Thanks ! Regards JB > Le 7 juin 2021 à 14:41, Gary Gregory a écrit : > > We've h

Re: [IO] Release 2.8.1 or 2.9 for IO-692 fix

ew it and consider the plan for a 2.9.0 version? > > Kind regards > Boris > > -Ursprüngliche Nachricht- > Von: Gary Gregory > Gesendet: Montag, 11. Januar 2021 17:49 > An: Commons Developers List > Betreff: Re: [IO] Release 2.8.1 or 2.9 for IO-692 fix > >

Re: [IO] Release 2.8.1 or 2.9 for IO-692 fix

/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) > at > > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at > > java

Re: [IO] Release 2.8.1 or 2.9 for IO-692 fix

In the meantime, you would be well advised to test with a 2.9.0-SNAPSHOT build. Gary On Fri, Jan 8, 2021, 09:50 Gary Gregory wrote: > I plan on creating a release candidate for 2.9.0 "soon", maybe > this weekend or next, no guarantees though... > > Gary > > On Fri, Jan 8, 2021, 05:18 wrote: >

Re: [IO] Release 2.8.1 or 2.9 for IO-692 fix

I plan on creating a release candidate for 2.9.0 "soon", maybe this weekend or next, no guarantees though... Gary On Fri, Jan 8, 2021, 05:18 wrote: > Dear IO developers, > > > > you already fixed https://issues.apache.org/jira/browse/IO-692 The > underlying issue blocks the component upgrade in

Re: [IO] Bundle-SymbolicName changed in 2.7+

Hi, In 2.6, 2.7, and 2.8.0, I see in MANIFEST.MF: Bundle-Name: Apache Commons IO Are you talking about a different name? Gary On Fri, Dec 18, 2020 at 6:53 AM Casey Lowe wrote: > I was trying to upgrade to the latest commons-io and noticed the bundle > name had changed. Given some older depe

Re: [IO] Using file filters with Java NIO file tree walking

On Wed, Oct 14, 2020 at 5:56 PM Bruno P. Kinoshita wrote: > Had a look at the commit [1] and found no issues. Really impressive work > Gary. You've updated the code and also added a lot of examples in the > Javadocs. Really golden. > Thank Bruno! > I used simple code snippets to understand ho

Re: [IO] Using file filters with Java NIO file tree walking

Had a look at the commit [1] and found no issues. Really impressive work Gary. You've updated the code and also added a lot of examples in the Javadocs. Really golden. I used simple code snippets to understand how the new API works, and quickly test it locally. But will try to update commons-im

Re: [IO] Using file filters with Java NIO file tree walking

On Sat, Oct 10, 2020 at 11:08 PM Bruno P. Kinoshita wrote: > Thanks for heads up Gary! Looking forward to reading/reviewing the new > code! > Bruno > Hi Bruno, It's in there now, feel free to take a look and review, change, or fiddle ;-) Gary > > On Sunday, 11 October 2020, 3:16:20 am N

Re: [IO] Using file filters with Java NIO file tree walking

Thanks for heads up Gary! Looking forward to reading/reviewing the new code! Bruno On Sunday, 11 October 2020, 3:16:20 am NZDT, Gary Gregory wrote: Hi All: FYI, I am working and nearly done adapting our file filters to work with java.nio.file.Files.walk APIs. My goal overall in Comm

Re: [IO][LANG][POOL][OTHER]

Le jeu. 3 sept. 2020 à 17:01, Gary Gregory a écrit : > > On Thu, Sep 3, 2020 at 10:47 AM Gilles Sadowski > wrote: > > > Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a > > écrit : > > > > > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept > > we > > > could reuse in Common

Re: [IO][LANG][POOL][OTHER]

On Thu, Sep 3, 2020 at 10:47 AM Gilles Sadowski wrote: > Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a > écrit : > > > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept > we > > could reuse in Commons components like IO, Lang, Pool (and by extension > > DBCP). > > > > Whi

Re: [IO][LANG][POOL][OTHER]

Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a écrit : > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept we > could reuse in Commons components like IO, Lang, Pool (and by extension > DBCP). > > While this might initially feel like a fit for Lang, I wonder what the > commu

Re: [IO] release candidate soon

On Thu, 3 Sep 2020 at 13:07, Gilles Sadowski wrote: > > Le jeu. 3 sept. 2020 à 13:55, sebb a écrit : > > > > On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > > > > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > > > > > Why so hurry? > > > > > > > > > > I need to use new APIs now. Rele

Re: [IO] release candidate soon

Le jeu. 3 sept. 2020 à 13:55, sebb a écrit : > > On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > > > Why so hurry? > > > > > > > I need to use new APIs now. Releases happen all the time, more releases > > more often is better than big b

Re: [IO] release candidate soon

On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > Why so hurry? > > > > I need to use new APIs now. Releases happen all the time, more releases > more often is better than big bang releases IMO, IOW RERO (Release Early, > Release Often). > > I

Re: [IO] release candidate soon

On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > Why so hurry? > I need to use new APIs now. Releases happen all the time, more releases more often is better than big bang releases IMO, IOW RERO (Release Early, Release Often). Is there any severe bug solved? > See changes.xml, severity is relati

Re: [IO] release candidate soon

Why so hurry? Is there any severe bug solved? And here goes another question. why is commons-io's group ID be commons-io but not com. apache. commons? Gary Gregory 于 2020年9月3日周四 上午1:57写道： > Hi all, > > I plan on cutting a release candidate very soon, probably tonight. > > Gary >

Re: [IO] Test failure in CircularBufferInputStreamTest

On Tue, 11 Aug 2020 at 01:20, Gary Gregory wrote: > > CI builds are failing in CircularBufferInputStreamTest with: > > [INFO] Running > org.apache.commons.io.input.buffer.CircularBufferInputStreamTest > [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: > 0.137 s <<< FAILURE!

Re: [IO] Test failures on Windows

That's what I meant; bug fixes will be included in normal releases. It's actually fairly similar to how the Jenkins LTS process works in that LTS releases are basically just points chosen in time to maintain as branches for backporting security fixes (slight difference being that in Jenkins, we "up

Re: [IO] Test failures on Windows

The question is, what do we do about File.lastModified() calls in Commons non-test code? On Sat, 8 Aug 2020 at 16:50, Gary Gregory wrote: > > FWIW, there recently was a bug found by Commons Lang in Java 15 and 16. > Java 16 has now fixed the bug but it will not be fixed in Java 15, at > least no

Re: [IO] Test failures on Windows

FWIW, there recently was a bug found by Commons Lang in Java 15 and 16. Java 16 has now fixed the bug but it will not be fixed in Java 15, at least not before GA. Gary On Sat, Aug 8, 2020, 11:45 Matt Sicker wrote: > Even if it’s fixed upstream, it’ll never get backported most likely. Even > c

Re: [IO] Test failures on Windows

Even if it’s fixed upstream, it’ll never get backported most likely. Even compiler bugs aren’t backported (see for example a bug related to reflection on intersection types that was fixed in Java 9; I can’t find an exact reference, but multiple bugs related to this were all address in 9). On Fri,

Re: [IO] Test failures on Windows

If so, then it is not sufficient to run tests on Windows, it looks like we need to run tests on Windows with the appropriate version of Java. Presumably that is why Jenkins did not show the error. However, fixing the test won't fix the code - there may be instances of lastModified elsewhere. The

Re: [IO] Test failures on Windows

On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker wrote: > That sounds like a file modification time granularity issue. Does Windows > not support milliseconds or finer for file modification times? It could be > that the test executed too fast! > This might be a classic bug I've run into at work: http

Re: [IO] Test failures on Windows

On Fri, Aug 7, 2020 at 10:09 AM Matt Sicker wrote: > You can basically copy the GitHub Actions setup we have in log4j2 minus the > toolchains stuff (unless you need that too). GHA looks to support macOS > runners as well. > It looks like we do it the same way... https://github.community/t/error-

Re: [IO] Test failures on Windows

I've just checked the Jenkins build and IO on Windows looks fine: https://ci-builds.apache.org/job/Commons/job/commons-net-windows/ On Fri, 7 Aug 2020 at 15:50, sebb wrote: > > On Fri, 7 Aug 2020 at 15:04, Matt Sicker wrote: > > > > That sounds like a file modification time granularity issue. D

Re: [IO] Test failures on Windows

On Fri, 7 Aug 2020 at 15:04, Matt Sicker wrote: > > That sounds like a file modification time granularity issue. Does Windows > not support milliseconds or finer for file modification times? Could be; I thought I had allowed for that. I'll see if I can fix it for Windows. > It could be that the

Re: [IO] Test failures on Windows

You can basically copy the GitHub Actions setup we have in log4j2 minus the toolchains stuff (unless you need that too). GHA looks to support macOS runners as well. On Fri, Aug 7, 2020 at 09:07 Xeno Amess wrote: > there be document on travis-ci about windows environment but I havn't seen > any j

Re: [IO] Test failures on Windows

there be document on travis-ci about windows environment but I havn't seen any java repo using it https://docs.travis-ci.com/user/reference/windows/ besides if my memory be correct, there be another site who have free windows environment. https://www.appveyor.com/ Gary Gregory 于2020年8月7日周五 下午10:

Re: [IO] Test failures on Windows

That sounds like a file modification time granularity issue. Does Windows not support milliseconds or finer for file modification times? It could be that the test executed too fast! On Fri, Aug 7, 2020 at 09:01 Gary Gregory wrote: > As of recently, I am seing: > > [INFO] Running org.apache.commo

Re: [IO] CharSequenceReader improvements

Thanks! On 10/07/2020 14:25, Gary Gregory wrote: Thanks Rob, I merged both PRs to master. Gary On Wed, Jul 8, 2020 at 3:49 PM Rob Spoor wrote: Hi, I was replacing my own copy of CharSequenceReader with the one from commons-io, but I had some test failures. I found out that there were two r

Re: [IO] CharSequenceReader improvements

Thanks Rob, I merged both PRs to master. Gary On Wed, Jul 8, 2020 at 3:49 PM Rob Spoor wrote: > Hi, > > I was replacing my own copy of CharSequenceReader with the one from > commons-io, but I had some test failures. I found out that there were > two reasons: > > * It doesn't override ready(), a

Re: [io] can we delete release 20030203.000550 in maven central?

s List Betreff: Re: [io] can we delete release 20030203.000550 in maven central? I suppose you can ask Sonatype to offer a sort by release date feature on that kid of query result. Gary On Sun, Jun 14, 2020, 10:44 Melloware Inc wrote: > Gary, > > Maven Central Search does no

Re: [io] can we delete release 20030203.000550 in maven central?

I suppose you can ask Sonatype to offer a sort by release date feature on that kid of query result. Gary On Sun, Jun 14, 2020, 10:44 Melloware Inc wrote: > Gary, > > Maven Central Search does not. Se ethos URL: > https://search.maven.org/search?q=g:commons-io > > Commons-IO 20030203.000550 is s

Re: [io] can we delete release 20030203.000550 in maven central?

Gary, Maven Central Search does not. Se ethos URL: https://search.maven.org/search?q=g:commons-io Commons-IO 20030203.000550 is shown as the latest version incorrectly. Mello On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory wrote: > I'm not sure what you are using, but Maven Central sorts by rel

Re: [io] can we delete release 20030203.000550 in maven central?

I'm not sure what you are using, but Maven Central sorts by release date: https://search.maven.org/artifact/commons-io/commons-io Gary On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote: > It is strange to have an older version have a larger major version number > than a newer version. > Of cours

Re: [io] can we delete release 20030203.000550 in maven central?

It is strange to have an older version have a larger major version number than a newer version. Of course we might never witness a major version whose number be 1000+ in our life, but... That just feels strange. Gary Gregory 于2020年6月14日周日 下午9:52写道： > On Sun, Jun 14, 2020 at 9:51 AM Xeno Ame

Re: [io] can we delete release 20030203.000550 in maven central?

On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess wrote: > Or if we should create commons-io2 and commons-BeanUtils2 like what > we've done in lang3, as @John Patrick suggested? > Why? Gary > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > > > > >

Re: [io] can we delete release 20030203.000550 in maven central?

Or if we should create commons-io2 and commons-BeanUtils2 like what we've done in lang3, as @John Patrick suggested? Gary Gregory 于2020年6月14日周日 下午9:39写道： > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > > > every time my update tool chain thinks 20030203.000550 is a greater > version > >

Re: [io] can we delete release 20030203.000550 in maven central?

On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > every time my update tool chain thinks 20030203.000550 is a greater version > than 2.7 (actually it is, if see it in number). > So have we some way to delete it from maven central? (or rename it?) > Yes, but we will never do that. That would br

Re: [io] can we delete release 20030203.000550 in maven central?

"update toolchain" here means idea's package plugin, which seems have no way to set up rules like rules in versions-maven-plugin. [image: image.png] Of course we can try to only use versions-maven-plugin. But a setting like that just hides problem, it does not solve the problem. The real problem i

Re: [io] can we delete release 20030203.000550 in maven central?

On 14/06/2020 12:40, Xeno Amess wrote: every time my update tool chain thinks 20030203.000550 is a greater version than 2.7 (actually it is, if see it in number). So have we some way to delete it from maven central? (or rename it?) The same problem happened in BeanUtils, version 20030211.134440

Re: [io] can we delete release 20030203.000550 in maven central?

I keep thinking that too, and ended up just using a custom versions rule to ignore it. Other idea maybe change to GAV to; 1) org.apache.commons:commons-io 2) org.apache.commons:commons-io2 So starting to match the commons-lang3 approach. I find commons-lang3 is a really good pattern and is much

Re: [io] BroadcastInputStream

Hi John, Please provide your proposal a PR on GitHub [1] so it can be better reviewed and built by Travis-CI. Gary [1] https://github.com/apache/commons-io On Sat, May 30, 2020 at 6:30 AM John Crowley wrote: > Have posted this to https://github.com/jcrowley66/BroadcastInputStream < > https://

Re: [IO] org.apache.commons.io.FileSystem for 2.7 or later

On Sat, May 9, 2020 at 7:49 AM Jochen Wiedmann wrote: > Looking at that class, it certainly seems to be a candidate for > refactoring. For example, I could imagine to split the actual > enumeration, and the implementation code into separate classes. But > that can be done after a release, just as

Re: [IO] org.apache.commons.io.FileSystem for 2.7 or later

Looking at that class, it certainly seems to be a candidate for refactoring. For example, I could imagine to split the actual enumeration, and the implementation code into separate classes. But that can be done after a release, just as well. So, I'd say: Just go for it, and don't bother ("Include

Re: [IO] and Javadoc library

On Mon, Apr 20, 2020 at 10:28 AM Matt Juntunen wrote: > I find them useful. We often use old versions in my day job and these > links are the quickest and easiest way to get to the docs. > What do you all think about pointing to https://javadoc.io/? for all old versions? > > -Matt > ___

Re: [IO] and Javadoc library

On Mon, Apr 20, 2020 at 11:55 AM Gary Gregory wrote: > On Mon, Apr 20, 2020 at 10:28 AM Matt Juntunen > wrote: > >> I find them useful. We often use old versions in my day job and these >> links are the quickest and easiest way to get to the docs. >> > > What do you all think about pointing to h

Re: [IO] and Javadoc library

I find them useful. We often use old versions in my day job and these links are the quickest and easiest way to get to the docs. -Matt From: Gary Gregory Sent: Monday, April 20, 2020 9:50 AM To: Commons Developers List Subject: [IO] and Javadoc library Currentl

Re: [IO] Release 2.7 soon

Very cool! Would it be possible to get this one included - https://github.com/apache/commons-io/pull/110 On Sun, 12 Apr 2020 at 17:54, Gary Gregory wrote: > > Hi All: > > It's been a long time since 2.6, so plan on cutting an RC for 2.7 soon-ish. > > Gary -- Adam Retter skype: adam.retter tw

Re: [IO] Travis build fails due to missing package documentation

Thanks for your pointer to your GH page, I'll take a look over the weekend... Gary On Tue, Nov 5, 2019 at 6:18 PM Rob Spoor wrote: > See https://travis-ci.org/apache/commons-io/jobs/607784753. The reason > is commit 14d6f4c6dbb429ebb915b530ea61fe911d36b20b, which added > interface IOConsumer in

  1   2   3   4   5   6   7   >