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

[Gary Gregory]

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'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 files = Files.getFiles(directory)
> List 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

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

[Elliotte Rusty Harold]

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:

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 files = Files.getFiles(directory)
List fileNames = Files.getFileNames(directory)

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

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Emmanuel: tomee does not use tomcat-dbcp, it facade any JDBC pool library
with its own code so any managed package usage is really legacy since ~10
years.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 juin 2023 à 14:18, Richard Zowalla  a écrit :

> David wrote something similar on the tomee dev@ list [1].
> So perhaps it would be worth to just provide a jakarta capable package?
>
> [1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc
>
> Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> > On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> >
> > > TomEE can drop managed package legacy dependency now, was kept
> > > while the
> > > replacement was in test in 1.x version but makes years it is no
> > > more
> > > relevant and no more the default (since we switched to tomcat-
> > > jdbc).
> > > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> >
> > Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> > the
> > managed package from tomcat-jdbc? If so we can't simply drop this
> > package from DBCP.
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

David wrote something similar on the tomee dev@ list [1].
So perhaps it would be worth to just provide a jakarta capable package?

[1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc

Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> 
> > TomEE can drop managed package legacy dependency now, was kept
> > while the
> > replacement was in test in 1.x version but makes years it is no
> > more
> > relevant and no more the default (since we switched to tomcat-
> > jdbc).
> > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> 
> Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> the 
> managed package from tomcat-jdbc? If so we can't simply drop this 
> package from DBCP.
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

On 26/05/2023 12:20, Romain Manni-Bucau wrote:


TomEE can drop managed package legacy dependency now, was kept while the
replacement was in test in 1.x version but makes years it is no more
relevant and no more the default (since we switched to tomcat-jdbc).
So no big deal if dbcp wants to drop it on TomEE side IMHO.


Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use the 
managed package from tomcat-jdbc? If so we can't simply drop this 
package from DBCP.


Emmanuel Bourg

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