Hi Elliotte, On Mon, Jun 19, 2023 at 4:08 PM Elliotte Rusty Harold <elh...@ibiblio.org> 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'd much prefer to use Apache Commons IO to handle a lot of > file system related tasks rather than reinventing and maintaining > those wheels ourselves. There's some common history here going back > 20+ years where code has been copied and pasted from one project to > the next, and then maintained and evolved with different levels of > care in different projects. > > I've found JDK or Commons IO replacements for almost everything I/O > related in our old utility library. I'm now down to the last group of > methods. These are several variants of getFiles/getFileNames that > return a list of the files inside a base directory as relative paths > from the base, either as String or File objects. There's nothing > exactly like this in commons IO. > > I think AccumulatorPathVisitor along with Files.walkFileTree covers a > lot of what it does. It's not a drop-in 1:1 replacement, but it should > suffice for most uses. The final missing piece is that the legacy > getFiles/getFileNames methods also support Ant includes and excludes > lists: > > @param includes the Ant includes pattern, comma separated > @param excludes the Ant excludes pattern, comma separated > > (I think this code originated in ant a couple of decades ago.) > > I think I can make this work with AccumulatorPathVisitor using a file > filter that accepts ant includes and excludes lists. My question is > twofold: > > 1. Would the commons IO project be open to accepting a contribution of > a file filter that is based on Ant includes and excludes patterns? No > actual ant code, just the pattern syntax described here:
Thank you for your offer! Yes but: 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 and/or lambdas would be fine, which would then enable Ant to pass its pattern syntax processor. > > https://ant.apache.org/manual/dirtasks.html#patterns > > 2. Would the commons IO project be open to accepting something closer > to the existing getFiles/getFileNames methods from maven-shared-util? > likely based on the file filter from #1 > > https://javadoc.io/doc/org.apache.maven.shared/maven-shared-utils/latest/org/apache/maven/shared/utils/io/FileUtils.html#getFileAndDirectoryNames(java.io.File,java.lang.String,java.lang.String,boolean,boolean,boolean,boolean) > > The current methods are a bit of a mess with an IMHO excessive number > of options and overloads, so it wouldn't be a pure copy of the API, > but it would be a single method that could do something like > > List<File> files = Files.getFiles(directory) > List<String> fileNames = Files.getFileNames(directory) Anything that returns a list, as opposed to a stream, feels wrong. We've seen plenty of cases where processing large directories and trees using lists is almost considered a bug at best and a DOS vector at worst. IOW, it can be a performance killer. WRT to dealing with methods that take many optional parameters, another option is to have a separate class with a builder. I'm not sure this is the best solution here, I'd need to see a few examples. Gary > > to return a List of files contained within a directory. I think the > implementation would be based on AccumulatorPathVisitor and > Files.walkFileTree rather than copying the current code that dates > back to something like Java 1.2. > > Thoughts? Is this something the commons IO project would be willing to > own? If so, I can file an issue and begin working on a PR. Thanks for > the consideration. > > -- > Elliotte Rusty Harold > elh...@ibiblio.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
