What is the best practice for managing javascript libraries (such as JQuery)?

The solutions I’ve seen remind me of .jar libary management practices in the 90’s. Namely, just download some version of the javascript library and stick it in your source directories somewhere. I feel that Javascript libraries are really binary dependencies and would like to just have the build pull them from a Maven2 repository somewhere and put it in the correct place in my webapp directory. Does anyone do this? How? Can you find these javascript libraries (such as JQuery) in a binary repository anywhere?

You can always host your own repository. We use Artifactory in our company and since we also work with C# we used it for those dependencies as well and it works just fine. You just have to set the type to ‘js’ when you declare the dependency.

If you look at this post http://forums.gradle.org/gradle/topics/checkstyle_plugin_wrapper you can see how to get the files from a configuration and put them somewhere, you can adapt this for your needs.

Thanks Luke, that worked perfectly. And thank you, too, Leonard, as you are correct we could put our JS libraries in our company Artifactory for internal project. In this case, I was working on an open source project, so that solution doesn’t work, but I will consider it for our internal projects as well.

I’m surprised that the web development community isn’t pushing for some standardization like this. But maybe they don’t like standards (seeing the mess that is HTML, CSS, web browsers, etc.). Perhaps this is just too far down on the list to get any attention. Anyway, these ideas work for me, so thank you both very much.

If you don’t mind having the jquery library hosted remotely you could refer to it directly, instead of deploying it yourself:

http://code.jquery.com/jquery-latest.min.js

Not directly an answer to the question, but more nice-to-know tools when working with JavaScript (and CSS):

  • Juicer - merges and minimizes JavaScript and CSS with JsLint support, CSS cache busters, image embedding and asset host cycling * webutilities - merges and minimizes JavaScript and CSS * jawr - merges and minimizes JavaScript and CSS * Sprockets - Ruby library for compiling and serving web assets, with declarative dependency management for JavaScript and CSS and a preprocessor pipeline which works with languages like CoffeScript, Sass and LESS * bundle_fu - RoR library for merging and minimizing JavaScript and CSS

Sprockets and bundle_fu are Ruby libraries, so are only included to see other ways of doing this.

Expanding on my answer (why is it not possible to edit a comment?):

Juicer is a build time tool, while webutilities and jawr are used runtime. jawr has several other features too.

Thank you. Below some changes to 1. rename the file to the original filename 2. add the files automatically to a generated war 3. add the file into a WTP tomcat runtime in eclipse

task fetchJs(type: Copy) {

from configurations.js

into “$buildDir/js”

rename{ String fileName -> fileName.replace(’-min.js’, ‘.min.js’) } // fixes mavenized filename } // include the js in the war war.dependsOn fetchJs

When including in eclipse, I rely on a property “eclipseWTPdir”, which is something like C:/workspaces/workspace1/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/appname

task ensureWTPjsdirExists << {

eclipseWTPjsdir = new File("$eclipseWTPdir/js")

eclipseWTPjsdir.mkdirs() } task js2wtp(type: Copy) {

description = ‘copies the java script libraries into the eclipse WTP runtime’

from configurations.js

into “$eclipseWTPdir/js”

rename{ String fileName -> fileName.replace(’-min.js’, ‘.min.js’) } // fixes mavenized filename } js2wtp.dependsOn ensureWTPjsdirExists // include the js in the wtp apps folder //eclipse.doLast{copyJsIntoEclipse}

The only thing not working is the integration in the eclipse task. I would love to have “gradle eclipse” also executing “js2wtp” to reduse the hassle for users.

This does not work on my side, since first the pom file is searched: * What went wrong: Could not resolve all dependencies for configuration ‘:js’. > Could not resolve jquery:jquery:1.9.1.

Required by:

:workspace:unspecified

Could not GET ‘http://code.jquery.com/jquery-1.9.1.pom’.

code.jquery.com

repositories {
 mavenRepo(name: "JQuery", url: "http://code.jquery.com") {
  pattern = "[module]-[revision](.[classifier]).[ext]"
 }
}
  configurations{
 js
}
  dependencies{
 js group: 'jquery', name: 'jquery', version: '1.9.1', classifier: 'min', ext: "js"
}
task fetchJs(type: Copy) {
 from configurations.js
 into "$buildDir/js"
}

Your script works fine for me. I don’t think that the fact that it doesn’t find a POM is the cause of your problem. Maybe it’s a network or proxy issue.

Thank you for the reply and for trying out. Probably you are right, I am located within a big company network. Alternatively I will deploy the jquery.js to our artifactory. I cannot recognize the proxy error from the log: 13:13:04.362 [DEBUG] [org.gradle.api.internal.externalresource.transport.http.HttpResourceAccessor] Constructing external resource: http://code.jquery.com/jquery-1.9.1.pom 13:13:04.362 [DEBUG] [org.gradle.api.internal.externalresource.transport.http.HttpClientHelper] Performing HTTP GET: http://code.jquery.com/jquery-1.9.1.pom 13:13:04.565 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection request: [route: {}->http://code.jquery.com][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10] 13:13:04.565 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection leased: [id: 0][route: {}->http://code.jquery.com][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10] 13:13:06.905 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Connection org.apache.http.impl.conn.DefaultClientConnection@6ac3ea8d closed 13:13:06.905 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Connection org.apache.http.impl.conn.DefaultClientConnection@6ac3ea8d shut down 13:13:06.905 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Connection org.apache.http.impl.conn.DefaultClientConnection@6ac3ea8d closed 13:13:06.905 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection released: [id: 0][route: {}->http://code.jquery.com][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10] can I? Is the route{} such a hint?

It seems npm (Node Package Manager, http://npmjs.org/) handles node.js packages (http://nodejs.org/). I couldn’t find decent integration with Gradle though, only this Maven plugin: http://blogs.mulesoft.org/introducing-the-npm-maven-plugin/

I like using the webjars project (http://www.webjars.org/). From their web site:

WebJars are client-side web libraries (e.g. jQuery & Bootstrap) packaged into JAR (Java Archive) files. >

  • Explicitly and easily manage the client-side dependencies in JVM-based web applications > - Use JVM-based build tools (e.g. Maven, Gradle, & SBT) to download your client-side dependencies > - Know which client-side dependencies you are using > - Transitive dependencies magically appear

Second on the webjars project

The method

mavenRepo

has been deprecated. How to migrate the example to method

maven

which should be used instead?

repositories {

maven {

url = ‘http://…’

}

}

But how to provide the pattern for the file to download? I found out you can use ivy instead:

ivy {
        url "http://code.jquery.com"
        layout "pattern", {
            artifact "[module]-[revision](.[classifier]).[ext]"
        }
    }

This is a great conversation that’s separate from the main topic, so I created a new topic to continue the discussion. Please reference the new topic here: How to fix deprecation message about “mavenRepo”

Why don’t you use Bower and Grunt to manage the dependencies of JS?

If you don’t mind having the jquery library hosted remotely you could refer to it directly, instead of deploying it yourself:

IT Company Dubai | IT Service Solutions Dubai

Explicitly and easily manage the client-side dependencies in JVM-based web applications

____________________ aliii