Add support for locator.properties #15
Conversation
| @@ -25,17 +28,22 @@ public class WebJarVersionLocator { | |||
| private static final String NPM = "org.webjars.npm/"; | |||
| private static final String PLAIN = "org.webjars/"; | |||
| private static final String POM_PROPERTIES = "/pom.properties"; | |||
| private static final String LOCATOR_PROPERTIES = "/locator.properties"; | |||
|
|
|||
| private static final String CACHE_KEY_PREFIX = "version-"; | |||
There was a problem hiding this comment.
I added this to avoid duplication of the string
| } | ||
| } | ||
| } catch (IOException e) { | ||
| throw new RuntimeException("unable to load locator properties", e); |
There was a problem hiding this comment.
Not sure if this exception should be rethrown, logged or just ignored (similar to version()). For now I opted for throwing.
| return value; | ||
| }); | ||
| return cache.computeIfAbsent(key, inspectableFunction); | ||
| } | ||
| } | ||
|
|
||
| final WebJarVersionLocator webJarVersionLocator = new WebJarVersionLocator(new InspectableCache()); | ||
| // enable inspection after webJarVersionLocator has been constructed, to ignore lookups caused by loading locator.properties | ||
| shouldInspect.set(true); |
There was a problem hiding this comment.
My first Idea was to modifiy the assertEquals calls for numLookups but I think that this is a better solution.
| } | ||
| } | ||
| } catch (IOException e) { | ||
| throw new RuntimeException("unable to load locator properties", e); |
There was a problem hiding this comment.
I think that this Exception should only happen if the the locator.properties was found but could not be read. So we should be good if there is no locator.properties - is that right?
There was a problem hiding this comment.
Yeah, LOADER.getResources returns an empty Enumeration when there are no files found. I verified that by removing the locator.properties from test resources.
|
Thanks for tackling this! Overall I think this looks good. Does this address everything you need for #13? |
|
Yeah, I am pretty sure, that this should be a proper solution for #13. Due to the fact, that all webjars should have thier content in I'm not sure about the performance impacts of the two variants, but maybe the |
|
Thanks! Since this is a change we'd like to have integrated into Spring, @dsyer want to review? |
|
If I’m reading it correctly this locator properties file kicks in whenever it is present (and mostly it would not be). So users don’t have to do anything unless they want to provide locator properties themselves, but libraries might do that for them most commonly. If all that is correct there’s nothing to be done to integrate with existing usage. |
|
I don't know if supporting GraalVM native images is in the scope of this library; if that's the case, I would suggest adding the following file {
"resources": {
"includes": [
{
"pattern": "\\QMETA-INF/webjars/locator.properties\\E",
"condition": {
"typeReachable": "org.webjars.WebJarVersionLocator"
}
}
]
}
} |
|
+1 for @bclozel proposal as well as doing a real test of a Spring application compiled to native to check this PR does not break native support (which was one of the goal of |
@dsyer Correct. As of now, the file would only be present if a user is adding it to support legacy webjars that would otherwise not be found, or by non-standard 3rd-party webjars. In theory, official webjars COULD provide the file going forward, but that is up to @jamesward or the webjars team to decide. Regarding native-image, I think if it is just about adding that json file, I would say we should go for it. but that again is up to james to decide. @bclozel @sdeleuze as I have no experience with graalvm/native-image at all, it would be awesome if one of you guys could help out with doing a native test for this. |
|
Thanks all! Yes, we definitely want to make sure this is all compatible with native image. So a test would be great. It's a bit of a lift and we should do it. In the meantime, question for @bclozel and @sdeleuze - if we include the resource-config, it is ok if the referenced file ( |
|
btw, thanks all! you're amazing and I really appreciate your support! |
With this PR I want to bring up a possible implementation for supporting legacy and custom webjars with webjars-locator-lite. I started the related discussion in #13.
Unfortunately there was no decision on how to implement this feature in the related issue, therefore I tried to come up with something based on the suggestions.
The Implementation provided by this PR looks for
META-INF/webjars/locator.propertiesfiles on the classpath and then reads them into aPropertiesinstance. I decided to use a pattern ofWEBJAR_NAME.versionas key in the properties file to have the option to add other properties in the future (and be more specific about the purpose of the property -> providing a version). The value for each key has to be the version of the webjar as used in the resulting path.When reading the
locator.propertiesthe.versionsuffix is removed and the given version is put into the cache. Before adding a given webjar version to the cache, it checks if the resulting path exists.The files are loaded in whatever order
LOADER.getResources()returns them.With this change, it is possible to support any legacy (e.g. bower) or custom webjar, as long as the basic path structure is valid (
META-INF/resources/webjars/WEBJAR/VERSION/any/folder/or.file)