Use DirectoryPathTree in codegen

[scrocquesel]

/cc @ppalaga

[ppalaga]

@aloubyansky any chance to add some JavaDoc to the classes under independent-projects/bootstrap/app-model/src/main/java/io/quarkus/paths? It is very hard to review this PR without knowing basic things about DirectoryPathTree, like are the paths Windows/Unix normalized? Are the visited paths relative? Are third party extensions even allowed to use it? Why is DirectoryPathTreeTest.walk using PathTree.ofDirectoryOrArchive(root) rather than new DirectoryPathTree(root) directly (how can I be sure that DirectoryPathTree is tested at all)?

[ppalaga]

Is there a regular Windows CI for DirectoryPathTreeTest?

[aloubyansky]

This test is a part of the Quarkus CI, which includes Windows.
There is more javadoc in the PathTree interface that at least IDEs properly display for the implementations too. The directory-based one is one of the available implementations. Generally, I'd suggest using PathTree.ofDirectoryOrArchive(path) which would return an impl based on the path.
PathTree API can be used in other extensions, the primary purpose of this API is to provide classpath resources to the classloaders and users of the ClassLoader API.
The Paths exposed through the PathTree API will depend on the FileSystem that created them. AFAICS, if you initialize the directory-based impl yourself, it does not make sure it's an absolute path and will use it as it is.
Yes, changing the unit test to instantiate the DirectoryPathTree directly would make more sense than relying on a facade API.

[scrocquesel]

This test is a part of the Quarkus CI, which includes Windows.
There is more javadoc in the PathTree interface that at least IDEs properly display for the implementations too. The directory-based one is one of the available implementations. Generally, I'd suggest using PathTree.ofDirectoryOrArchive(path) which would return an impl based on the path.
PathTree API can be used in other extensions, the primary purpose of this API is to provide classpath resources to the classloaders and users of the ClassLoader API.
The Paths exposed through the PathTree API will depend on the FileSystem that created them. AFAICS, if you initialize the directory-based impl yourself, it does not make sure it's an absolute path and will use it as it is.
Yes, changing the unit test to instantiate the DirectoryPathTree directly would make more sense than relying on a facade API.

@ppalaga for now, I didn't want to use the factory abstraction because wsdl2java would not be able to process file inside archive. This would need to copy files in a temp directory. I plan to do this to be able to import wsdl from imported dependencies.

[aloubyansky]

@scrocquesel the tree returned from the facade API will depends on the input you provide. If you provide a directory, it'll be based on the default FileSystem. If you provide an archive, it will be a directory-based tree but based on the ZIP FileSystem impl.

[ppalaga]

This test is a part of the Quarkus CI, which includes Windows.

Perfect, thanks!

There is more javadoc in the PathTree interface

Thanks for pointing to that, the JavaDoc there is really useful. Having some JavaDoc on PathVisitor and PathVisit would be nice too, esp. the info which paths are relative and relative to what.

[aloubyansky]

I added a bit javadoc here quarkusio/quarkus#31939