createSmithyJarManifestUrl
: incorrect handling of complex paths
#2103
Labels
needs-reproduction
This issue needs reproduction.
Hi! I first bumped into this over a year ago, but so far had a workaround that seemed decent, and the usecase seemed pretty niche. Now me and my team maintain about 4 copies of the same workaround, so it's reaching a point where it'd be best to resolve upstream - right here.
What I'm trying to do
Originally, here's how we did it in smithy4s:
So far so good.
The problem
Trouble begins when certain artifacts are involved, namely:
For example,
org.polyvariant:test-library-core_2.13:0.0.1+123-SNAPSHOT
from Sonatype Snapshots would be placed in:Here's what happens when you use that file with
ModelDiscovery
:createSmithyJarManifestUrl
yields this URL:jar:file:$COURSIER_CACHE_LOCATION/v1/https/s01.oss.sonatype.org/content/repositories/snapshots/org/polyvariant/test-library-core_2.13/0.0.1%2B123-SNAPSHOT/test-library-core_2.13-0.0.1%2B123-SNAPSHOT.jar!/META-INF/smithy/manifest
- so far so good, it seemsfindModels
fails withModelManifestException
caused byFileNotFoundException
. the path that cause reports is$COURSIER_CACHE_LOCATION/v1/https/s01.oss.sonatype.org/content/repositories/snapshots/org/polyvariant/test-library-core_2.13/0.0.1+123-SNAPSHOT/test-library-core_2.13-0.0.1+123-SNAPSHOT.jar
- the urlescaping is gone now.I think this is an issue with
ModelDiscovery.findModels
.The expected behavior can be achieved with the following workaround: treat the jar as a FileSystem, and use the Path API to get an URL:
The
path.toUri()
part stringifies as:jar:file://$COURSIER_FILE_LOCATION/v1/https/s01.oss.sonatype.org/content/repositories/snapshots/org/polyvariant/test-library-core_2.13/0.0.1%252B123-SNAPSHOT/test-library-core_2.13-0.0.1%252B123-SNAPSHOT.jar!/META-INF/smithy/manifest
- which, to me, sounds correct.Request
I think there's more than one issue here:
createSmithyJarManifestUrl
going from URL (a relatively structured type) to aString
(no structure at all), offering little to no type safety when it's used down the linefindModels
doing something strange with its parameter, discarding the urlencoding of the given path.so the ideal solution would also be twofold:
URL
orURI
findModels
Context, if you want to learn more about the issue we had and the workaround: disneystreaming/smithy4s#850
Notes / questions
ModelAssembler
?The text was updated successfully, but these errors were encountered: