The path to a WebJar's contents must be in the form:
META-INF/resources/webjars/${name}/${version}
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.
The version number must only be in the WebJar path, not in files.
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.
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.
The artifactId should always be lowercased. It can be built from (by order of preference):
The name used for bower / npm releases of the library
The upstream GitHub repository name of the library
The name of the library
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
The purpose of a WebJar build is to download a specific version of a web library and package it into the WebJars form.
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.
A starter Maven build pom.xml file looks like:
Releasing WebJars
The webjars.org website pulls its list of WebJars from artifacts with a groupId of org.webjars on Maven Central.