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 <garydgreg...@gmail.com> wrote: > 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 > > >
