search

stomp-js / stomp-websocket

Stomp client for Web browsers and node.js apps
https://stomp-js.github.io/stomp-websocket/
Apache License 2.0
141 stars 36 forks source link

Header escape #17

Closed kum-deepak closed 6 years ago

kum-deepak commented 6 years ago

I will wait for few days then merge and release a new version.

Toparvion commented 6 years ago

Slightly off-topic but still related question: do you plan to release your library branch as webjar like original library was (e.g. on Maven Central)? It would greatly help its adoption in JVM world.

kum-deepak commented 6 years ago

I actually don't know how it is done. Will you be able to help?

Toparvion commented 6 years ago

Yes, I think. I already have a project there. It is a plain library jar (not webjar) but I think there shouldn't be significant difference.

Toparvion commented 6 years ago

I've observed the process of webjar publishing and realized that it is completely different from the one of usual Java libraries (none the less). It doesn't seem complicated at all but involves remarkable amount of owner-specific data so that it would make sense to do it by yourself in order to avoid excess delegating.

kum-deepak commented 6 years ago

Actually I published the Webjars, or at least I think so. Please search for stompjs at http://www.webjars.org/

I used the option Add a WebJar on the left of the search box and used the npm option.

I will find a way to automate it so that I can hook it to the npm release process.

Toparvion commented 6 years ago

Yes, you're right - there is stomp__stompjs artifact appeared in Maven Central repository. You can check it at:

I've tried to include the library as a webjar into my Gradle project with these two lines of code:

  1. compile group: 'org.webjars.npm', name: 'stomp__stompjs', version: '3.1.1' in Gradle script
  2. and <script src="webjars/stomp__stompjs/3.1.1/lib/stomp.js" type="text/javascript"></script> in web page (intentionally ignored minified version)

and it works. Thank you!

I don't actually understand the difference between the simple releasing way you've found and the one I 've mentioned above. Nevertheless the result is good enough not to waste time on it anymore.

I think you can include the first line (or its Maven analog) into the documentation as an alternative for downloading flat files. It is the most commonly adopted way of dependency resolution in (especially large) JVM applications.