Designing a Javascript Maven Plugin


As mentioned in my previous post, I believe that the tooling for enterprise grade javascript applications is simply not there yet. What is needed is a set of tools, preferably open source, that are framework agnostic and that fit into established development practice. In this and the subsequent posts, I will walk you through the process of building just this toolset using the Maven as a framework to glue it all together.

Overall Philosophy

First and foremost, the toolset must be independent of the code that is written. We simply cannot have a compiler that will only work for JQuery, or a testing harness that will only work if the test artifacts are composited via Rake.

Furthermore, I would like to adhere to Java conventions as much as possible, by which I mean JSDoc, JUnit-style unit tests and so forth. Java is syntactically very close to Javascript and Java’s strong prevalence in the enterprise space will reduce engineer friction.

The project artifacts will be packaged in as close to a native file type as possible. This becomes tricky: For something like a Javascript Library, a simple minified .js file will do. For a full web application with images, media, html and more this will be trickier as the nature of the server will define one packaging type over another: Jetty/Tomcat will prefer a .jar file, Apache will serve up an uncompressed archive, and so forth.

When possible, we’re going to take advantage of the latest and greatest: CSS compilers, for instance.

Why choose maven?

Maven is an obvious choice for various reasons. Firstly, it enjoys broad IDE integration. Secondly, it has an extremely powerful plugin framework that allows a user to use entire groups of plugins or focus on only the ones they really need. Thirdly, its dependency resolution mechanism is very powerful and very portable, which makes your builds extremely easy to bring to other platforms. Fourthly, it is open source and well supported by the community. Lastly, it enjoys broad support among continuous integration frameworks. All of these together make it a no-brainer to use as the core engine for our javascript toolset.

What workflow steps are needed?

Since maven defines a specific artifact lifecycle, we should start there and decide what we need our plugin to do. After starting to write this for a little bit however I realized that trying to declare it all up front is a significant undertaking, and should be split up by broader concepts:

  1. Compilation
  2. Optimization
  3. Unit Testing
  4. Functional Testing
  5. Packaging and Publishing
  6. Dependency Resolution
  7. Debug Runtime
  8. Headless Runtime
  9. PMD/Linting
  10. Documentation
  11. Reporting

Should we create an Archetype?

The short answer: Yes. The long answer: Archetypes are absolutely critical to drive adoption, examples and acceptance, and are a very useful speed-of-workflow tool. Given the many different potential framework projects out there however, we’re going to have to create many of these; One for JQuery, one for Mootools, one for Backbone… you get the idea. So how about we worry about that once we get more pieces of the compiler in place.

Where will the source live?

I’m glad you asked! I’ll be hosting the project on GitHub. Please feel free to contribute!

Where will the maven repository be?

This is as yet undecided. For now I recommend you clone the project and install it locally. Once there’s enough functionality on the project to warrant a full point release, we’ll revisit this.

2 Comments

  • Sal

    Has there been any update on this project? How do i use it? I am desperately looking for a maven archetype for creating javascript projects and plugins for minifying javascript and concatenating/merging the javascript in various files into one big file automatically..

  • Not in the last month, no. I've been putting my time into a javascript framework, but I've been planning to pick this up again this weekend.

Leave a Reply