Working with Windows paths is difficult #52
Description
Similar to #22, #23, #47 and #51, I ran into issues trying to specify a URI composed of Maven placeholders such as ${project.basedir} and ${project.build.directory}.
I found that in some cases to have the URI parse correctly, I needed a single slash at the beginning, i.e.:
file:/${project.basedir}/src/main/charts/${project.artifactId}
But in other places in the code, there is a call to URI.getPath() where the result is passed to Paths.get(), and this fails because paths like /C:/Users/whatever/project cause an exception in Paths.get(). If Paths.get() is passed the actual URI instance, it does work, but passing it the string from getPath() does not.
Also, the fix for #47 only addressed the chart contents location - I ran into basically the same issues with the chart target URI.
To work around these issues, I created a patch that introduced two additional parameters: chartContentsFile and chartTargetFile, injected as File objects, and set up the code to call toURI() on these if they were present and the corresponding URI was not set. Then I also changed the calls that constructed Path instances to avoid using the getPath() and this got me to a point where the mojo would run easily across platforms. Also the use of File made it simpler to work with a relative path, which was not possible with the URI.
I have attached a patch to the PackageMojo.java class showing what I did in case it is useful to integrate or for others who wish to work around this on Windows.