Understanding WebJars

  1. The path to a WebJar's contents must be in the form:
    This path structure was chosen because it can be universally supported by Java Web Frameworks and by including the version number in the path, far-future-expires can be easily used for aggressive caching.
  2. The version number must only be in the WebJar path, not in files.
  3. The version number is the upstream version, not the WebJar version. Most of the time these are the same. But sometimes there are packaging bugs in a WebJar that cause a version bump in just the WebJar version.
  4. The upstream source must be a versioned artifact. If the upstream source doesn't provide a released version then either use a commit date + git commit ID (eg. 20140708-394bf29) or fork the upstream project and apply semantic versioning.
  5. The artifactId should always be lowercased. It can be built from (by order of preference): If the upstream source is a fork of an official library then the artifactId should indicate that, like "jquery-foo" where "foo" is the fork owner.

Building WebJars

  1. The purpose of a WebJar build is to download a specific version of a web library and package it into the WebJars form.
  2. WebJars typically use the Maven build tool.
  3. Simple web libraries may be downloaded as it's individual source files. But usually the web library is downloaded as zip file, then extracted and arranged into the right form.
  4. A starter Maven build pom.xml file looks like:


Releasing WebJars

  1. The webjars.org website pulls its list of WebJars from artifacts with a groupId of org.webjars on Maven Central.
  2. Currently the artifactId of a WebJar must match a repo in the webjars organization on GitHub.
  3. To get a WebJar listed on the webjars.org website, create your own GitHub repo containing the Maven build for the new WebJar.
  4. Then open a new WebJar request and indicate your GitHub repo.
  5. Your repo will be forked into the webjars organization on GitHub, then tested and released to Maven Central.