Closed drdamour closed 9 years ago
I second that request. A Webjar would be perfect for consumption within Java projects. However, at least creating some releases (tags?) would help downstream consumption of the browser. Currently you have to copy the files from an arbitrary commit and bundle it with your app somehow.
webjar would be good - it was my first thought after 'this all looks really great'. Cheers.
@andrekampert did the job https://github.com/Product-Foundry/hal-browser-webjar, but it seems a fork request to webjars.org is missing (https://github.com/Product-Foundry/hal-browser-webjar/issues/1)
Release request created at https://github.com/webjars/webjars/issues/946
Great, thanks guys
It's now listed in webjars at https://github.com/webjars/hal-browser so I suppose you could close this ticket.
ok :+1:
fyi, there's still some friction for webjars since this repo doesn't use revision / releases but yay!
I know. That's why I worked with @jamesward to push out a release to webjars. If this project would start doing releases, then its not hard to update the process.
You need me to start using github releases? That's no problem, really
Spring-HATEOAS is supporting HAL OOTB and it also has support for webjars as it's built on Spring MVC. Wrapping up the hal-browser into a webjar would be a great way to deploy it side by side with any Spring-HATEOAS implementation.
All that would need to happen is for someone to make releases on github for each significant milestone and leave it for all eternity (a small commitment). They don't even have to be major version numbers. 0.1.0 is fine...but they should follow semantic versioning.
I'm happy to put together the webjar package and submit it if a release is published on GH.