Stable release planned?

[dsyer]

Thank you for publishing the 0.0.1 version of this library. A lot of people (including the Spring Framework team) will be hesitant to depend on a 0.0.1 version. Is there a plan for 1.0.0? Any reason to believe the API isn't stable?

A related question is: could the "core" library depend on this one, and skip the infamous classgraph initialization for simple use cases?

[jamesward]

Sorry I missed this! I think there are two things to move to a 1.0.0 release:

• Some validation / feedback on the API (I don't know if anyone has really tried this yet - total Maven Central downloads are under 100)
• It'd be great to get some updated docs and a sample app with Spring: https://www.webjars.org/documentation
• I'd still like to see if we can add some caching since doing a classpath read on every resolve has a lot of unnecessary overhead

BTW, the Bower WebJar deprecation plan has begun rollout so I feel good about that part: webjars/webjars#2039

[sdeleuze]

Thanks for your feedback, I guess I could take care of the validation/feedback + share some updated docs and sample with Spring that you could integrate if we go that path.

That said, I would like to double check with you: after Bower WebJar removal, wouldn't it be possible to remove scanning from webjars-locator-core as discussed in webjars/webjars-locator-core#96? Because if that's the case, we could also just wait for that to happen, and get more reasonable performances out of the box without requiring changes on users projects or in Spring, which could be a huge win for everybody. Any thoughts?

[jamesward]

Yeah, in Feb 2025 with Bower WebJar support being removed, we can probably replace the implementation of webjars-locator-core with webjars-locator-lite but I'm not sure if we should do that via a dependency or by deprecating webjars-locator-core and just recommending people use webjars-locator-lite. I think the primary remaining functionality delta between the two is the extractor stuff so we'd have to figure out where that lives if we were to completely deprecate the webjars-locator-core library.

[sdeleuze]

Let me have a deeper look, and I will provide my feedback.

[sdeleuze]

I was initially more on the side of leveraging webjars-locator-core dependency, but evolving WebJarAssetLocator API and implementation may add an additional delay to the Feb 2025 date, could be challenging, and I think webjars-locator-lite will give to the ecosystem more flexibility to evolve faster towards a more efficient version of WebJars while not breaking others.

So my proposal is to move forward with making webjars-locator-lite 1.0 to just have the API surface and implementation needed. I will experiment on Spring side to add support for it in WebJarsResourceResolver, while keeping support for webjars-locator-core for now. I will provide a feedback here in term of API, efficiency, performance and compatibility with native image.

As a consequence, I am reopening spring-projects/spring-framework#27619 and plans to implement it as part of Spring Framework 6.2, with the ask that webjars-locator-lite:1.0.0 should be published before Spring Framework 6.2.0-RC1.

[sdeleuze]

The support I implemented in sdeleuze/spring-framework@gh-27619 seems to work as expected (modulo adaption needed on Spring Boot side), it speedups application startup compared to webjars-locator-core, supports both versioned and version-less URLS, and provides the same throughput based on my test (4000 req/s on my M2 Pro).

What I would need to check with you @jamesward before merging this:

• Do you want to plan to implement caching to make it even faster?
• Could you please double check the API is stable and do changes if required? For example, do you plan to keep those static methods in WebJarVersionLocator or do you prefer to switch to instantiating the class and non static method? If future features like caching require instantiation, the design of the API should anticipate the upcoming need.
• When the previous 2 points are handled, could you please release a less scary version number? If possible, could we use a regular 1.0.0 version instead of the 0.xy pattern used in webjars-locator-core?

FYI, in terms of timing, Spring Framework 6.2.0-M1 is planned to be released April 11th.

[jamesward]

Sweet! Thanks @sdeleuze.

I think getting caching in now is important because as you mention, it could impact the API. I could whip up something based on ConcurrentHashMap and have a constructor that takes a new interface like WebJarsCache to hide the impl. Wdyt? I can get this done today.

[jamesward]

Cache impl is ready for review: #4

cc @dsyer

[jamesward]

I've released 0.0.2 with the cache addition. Let's verify that it works @sdeleuze and then I can do a 1.0.0 release.

[jamesward]

I've released 0.0.3 - details: https://github.com/webjars/webjars-locator-lite/releases/tag/webjars-locator-lite-0.0.3

[sdeleuze]

Support added in Spring via spring-projects/spring-framework#27619. I propose we wait feedback after Spring Framework 6.2 M1 is released April 11th, and release webjars-locator-lite 1.0.0 before Spring Framework 6.2 M2 planned May 16th.

[jamesward]

Sounds great!

[jamesward]

I've released 0.0.4 with a new path method for cases when the META-INF/resources/webjars should be omitted (like when that has been setup with routing elsewhere. Anything else needed before a 1.0.0 release?

[sdeleuze]

On Spring side, nothing more than potential feedback once 6.2 M1 is released.

[jamesward]

Cool. So you are good with 0.0.4 in Spring 6.2 M1 then getting feedback and then later doing a 1.0.0 ?

[sdeleuze]

Yep, I have already upgraded Spring to 0.0.4.

[sdeleuze]

@jamesward No issue reported on Spring side so far, so no blocker for 1.0.0 release from our side.

[jamesward]

Cool. Getting ready for the 1.0.0 I realized that it'd be more consistent to have the version method be just version instead of webJarVersion and have deprecated the webJarVersion method:
e6edb22

I haven't released 1.0.0 yet as I wanted to check that it is ok to make this change. Thinking better to change it now than later. LMKWYT

[sdeleuze]

With the deprecated method I guess that's ok, but given the recent comments, let's fix #8 before releasing 1.0.0 if that's ok for you.

[sdeleuze]

@jamesward Maybe you want to refine the Javadoc here? I am also wondering if the signature should be declared as Optional<@Nullable String> computeIfAbsent(String key, Function<String, Optional<@Nullable String>> function) in WebJarCache and WebJarCacheDefault in order to take in account the fact the function can return null.

@dsyer @vpavic If you can, maybe give a quick look to the latest WebJarCache contract here and related implementation/usage to check if that's ok from your POV.

[jamesward]

Thanks for the review. I think I actually want those to be Optional<@NotNull String> as a null in the computeIfAbsent should instead be represented as Optional.empty - does that sound right?

[sdeleuze]

Yeah you are right, computeIfAbsent itself does not return null.

But instead of specifying Optional<@NotNull String>, I would advise to add a @NullMarked annotation to WebJarCache and WebJarCacheDefault, and we should be good for 1.0.0.

[jamesward]

Thanks. I'm not familiar with @NullMarked - does this look right? 9959870

[vpavic]

I just caught up with the activity on all the related issues over the last couple of days - maybe I'm missing something, but as per my comment in #4 (comment), is there really a need for cache abstraction at all for the initial release?

It seems to me (judging by @sdeleuze comment in #8 (comment)) that all sides are OK with cache being enabled by default, so that IMO means there's no imminent need for cache abstraction - might be my just personal preference, but it seems that it's better to keep things as lean as possible for 1.0.0 and wait for a real use case to come up with cache abstraction (which might not happen ever).

[sdeleuze]

Thanks. I'm not familiar with @NullMarked - does this look right? 9959870

Looks good, that's set the default to @NotNull on all annotated scope APIs (I simplify a bit). An alternative would have been to set that at package level but since Core and Lite have the same package (but are not expected to be used together), I think that's better to set it at class level.

If we don't have yet a use case for custom or disabled caching, I can understand @vpavic proposal to not expose it initially (by removing the WebJarVersionLocator related constructor and either by using directly ConcurrentHashMap or making WebJarCache/WebJarCacheDefault package private). Up to you @jamesward. As we usually say in the Spring team in term of API: "a no is temporary, a yes is forever" (modulo deprecation for removal).

[jamesward]

I do provide a different impl for the test, but yeah it could be made package private to accomplish that. Seems like a good idea for now. I'll get that done shortly.

[sdeleuze]

Thanks James. Last thing is also to decide if you remove webJarVersion() or not before 1.0.0. IMO you could (Spring don't use it).

When you are ready, let me know if I should test with Spring the snapshot or a potential 0.0.6 before pushing the 1.0.0 release button, and we should be good to go GA.

[jamesward]

Thanks! Here are those changes:
b5f34a2

0.0.6 is being released now for testing.

[sdeleuze]

I have tested with my demo application and Spring Framework test suite with 0.0.6, all good.
And the changes looks fine from my POV, so green light for releasing 1.0.0 from my POV.

[jamesward]

Thanks! I'll give it until Monday to see if anyone else has feedback.

[jamesward]

I've released 1.0.0 - thanks everyone for the help!