Move to Path API (and increase major version to 4)

[laeubi]

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:

1. Items are not required to be "traditional" local files, but can be anything (e.g. Webdav)
2. Many utility methods might be obsolete and can be replaced with standard java
3. A File can easily be converted to a Path (and back if one is only want to work with local files), so existing code can upgrade without much effort.

[michael-o]

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]

@slawekjaranowski @khmarbaise

[laeubi]

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.

I don't fully understand, as my proposal is to delete such obsolete ones (as Path API provides them already) but for example

https://github.com/codehaus-plexus/plexus-utils/blob/7f7929f6ec70228968c4ba1159777827c15cdd7e/src/main/java/org/codehaus/plexus/util/Scanner.java#L86

currently requires File that would be a place where I like to change to Path and if thats done all over the place then many helper methods might be obsolete already...

[michael-o]

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.

I don't fully understand, as my proposal is to delete such obsolete ones (as Path API provides them already) but for example

https://github.com/codehaus-plexus/plexus-utils/blob/7f7929f6ec70228968c4ba1159777827c15cdd7e/src/main/java/org/codehaus/plexus/util/Scanner.java#L86

currently requires File that would be a place where I like to change to Path and if thats done all over the place then many helper methods might be obsolete already...

Yes, yes. Our both understanding is identical. First sweep, then move to Path.

[slawekjaranowski]

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]

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 ...

We need to get rid of duplicates first. It is just unacceptable for volunteers to have many copies of the same.

[laeubi]

We also have m-shared-utils ....

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 Scanner implementation as a showcase? e.g looking at the default exclude patterns and alike it seems very cumbersome to really replicate this. This still would require

• #226

as a minimal change...

We need to get rid of duplicates first. It is just unacceptable for volunteers to have many copies of the same.

But how to proceed here? Who decides what is the duplicate (and possibly takes care of removing it)?

[michael-o]

We also have m-shared-utils ....

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 Scanner implementation as a showcase? e.g looking at the default exclude patterns and alike it seems very cumbersome to really replicate this. This still would require

* [Use Path in the Scanner API #226](https://github.com/codehaus-plexus/plexus-utils/pull/226)

as a minimal change...

We need to get rid of duplicates first. It is just unacceptable for volunteers to have many copies of the same.

But how to proceed here? Who decides what is the duplicate (and possibly takes care of removing it)?

I would assume that Scanner and 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.