Add function to normalize path between different OS

[Azurelol]

Description

Adds the normalizePath function on PropertyUtils, meant to replace IntegrationSpec.osPath in the commons-test library.

For example, given the path /foo/bar, on the following systems:

• Windows: c:/foo/bar
• Macos: /foo/bar

Changes

• PropertyUtils : normalizePath

[Larusso]

hmm I'm not quite sure how this should be used. If I have a relative path you will resolve it based on the root path given. Java has all these methods build in with the java.io.File Api

public String getAbsolutePath()
Returns the absolute pathname string of this abstract pathname.
If this abstract pathname is already absolute, then the pathname string is simply returned as if by the getPath() method. If this abstract pathname is the empty abstract pathname then the pathname string of the current user directory, which is named by the system property user.dir, is returned. Otherwise this pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.

Returns:
The absolute pathname string denoting the same file or directory as this abstract pathname
Throws:
SecurityException - If a required system property value cannot be accessed.
See Also:
isAbsolute()

I think the functionality you are describing in combination with a root path is resolve path

Path resolve(Path other)
Resolve the given path against this path.
If the other parameter is an absolute path then this method trivially returns other. If other is an empty path then this method trivially returns this path. Otherwise this method considers this path to be a directory and resolves the given path against this path. In the simplest case, the given path does not have a root component, in which case this method joins the given path to this path and returns a resulting path that ends with the given path. Where the given path has a root component then resolution is highly implementation dependent and therefore unspecified.

Parameters:
other - the path to resolve against this path
Returns:
the resulting path
See Also:
relativize

We need to be carful what a single helper method can do under the hood and what the expectations are.

For instance I think it would fail if the method is provided with these parameters on windows:

normalizePath("/root/path", "c:/another/root" -> c:/another/root/c:/root/path

a root directory to start from if the path is found to be relative

There is no early return if the path is absolute.

[Azurelol]

There not need be an early return in this case.

[Azurelol]

I am a bit confused on you mentioning you are not sure how this method could be used, as its meant to be the successor to osPath, which we liberally use throughout our tests. I just want to write in a more robust way.

[Larusso]

You added functionality that was not in the old method. So if it is a successor I wonder where the resolve parts are used.
I see the else if must have overlooked it. But I personally would not mix to many things into one wonder function. It doesn't compose well. I would simply like to see where you need at the moment the functionality to resolve relative paths with a root directory because as I showed you there are builtin methods for that.

Also you don't validate the root directory. You take it as face value that this could be either in the correct format or not. At the very least you should call normalize again on that path to make sure it is in the correct format for the current platform.