Repository navigation
Move to Path API (and increase major version to 4) #224
Description
Currently this uses java File API, I wonder if it would be suitable to start a new major release and migrate to the Java Path API? This has several advantages:
- Items are not required to be "traditional" local files, but can be anything (e.g. Webdav)
- Many utility methods might be obsolete and can be replaced with standard java
- A
Filecan easily be converted to aPath(and back if one is only want to work with local files), so existing code can upgrade without much effort.
Activity
michael-o commentedon Nov 23, 2022
I wouldn't waste any single second on classes or methods which duplicate Apache Commons or other libs. We partially have the same code several times. This must be reduced to a bare minimum first.
michael-o commentedon Nov 23, 2022
@slawekjaranowski @khmarbaise
laeubi commentedon Nov 23, 2022
I don't fully understand, as my proposal is to delete such obsolete ones (as Path API provides them already) but for example
plexus-utils/src/main/java/org/codehaus/plexus/util/Scanner.java
Line 86 in 7f7929f
currently requires
Filethat would be a place where I like to change toPathand if thats done all over the place then many helper methods might be obsolete already...michael-o commentedon Nov 23, 2022
Yes, yes. Our both understanding is identical. First sweep, then move to
Path.slawekjaranowski commentedon Nov 24, 2022
We also have m-shared-utils ....
https://github.com/apache/maven-shared-utils/blob/25532658debe5bf2c55df7a61e6c6ad388640469/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L273-L281
Too many utils ...
michael-o commentedon Nov 24, 2022
We need to get rid of duplicates first. It is just unacceptable for volunteers to have many copies of the same.
laeubi commentedon Nov 24, 2022
This one is marked deprecated and one should use "java.nio.file.DirectoryStream and related" but I must confess it seems hard to guess how "java.nio.file.DirectoryStream and related classes" should replace this? Can someone came up with a compliant
Scannerimplementation as a showcase? e.g looking at the default exclude patterns and alike it seems very cumbersome to really replicate this. This still would requireas a minimal change...
But how to proceed here? Who decides what is the duplicate (and possibly takes care of removing it)?
michael-o commentedon Nov 24, 2022
I would assume that
Scannerand friends must be wrappers around NIO 2 only.I truly appriciate the effort and engagement, but I want to focus your time and energy at exactly one codebase. We should create a listing of all classes, diff them, no change decide where it will go. All in a new major version.