After another long period of having nothing to say, I’ve pushed out an update to jslint4java. Version 2.0.2 doesn’t include any major new features, but does update JSLint to the latest version (2012-02-03) and fix a couple of small bugs here and there.
- issue 75: Handle BOMs when using the CLI.
- issue 74: Document the technique for construction of JSLint objects.
- issue 73: Better examples for maven configuration.
- issue 72 : Add all formatters to the maven plugin automatically.
- issue 67 : Fix maven docs.
- Update to JSLint 2012-02-03.
- This removes the
- This adds the
One minor point: Now that google code supports git repositories, I’m also pushing the source code there again. Github is still my “primary” but there’s another copy. More copies are good.
I did spend a bit of time testing the CLI interface properly. This isn’t really noteworthy, but it was entertaining for me, and hopefully results in fewer bugs like issue 75.
Only about a month later than I had hoped, I’ve published jslint4java-2.0.1. The main change should be that the maven plugin is a bit better behaved. Plus of course, it’s using the latest version of JSLint.
I’ve finally released jslint4java 2.0.0. It’s now available at code.google.com/p/jslint4java. The main new feature is that it now sports a maven plugin in addition to the ant task.
There is also a breaking change, that’s been inherited from JSLint. The meaning of several options has been inverted. Now, the default is to behave strictly, with options turned off. For example, if you want to turn off JSLint’s checking of whitespace, you now have to specify
--white. Previously, this would enable checking of whitespace. See the release notes for details, and please take care when updating.
The maven plugin should behave much like any other maven plugin: you add it to your
<build><plugins> section. Here’s an example:
I’d love feedback on how well this works.
I’ve released a minor update, 1.4.7. It’s available from the usual place.
- Added OSGI bundle headers.
- I’m an OSGI novice; please let me know if these are wrong.
- issue 52: Add checkstyle xml formatter.
- issue 53: No files passed to the ant task is no longer an error (just an info message).
- Update to JSLint 2011-03-07.
- This adds the
continue option, whilst removing
- JSLints interpretation of line and column numbers has changed. I’ve tried to keep up. Please file a bug if errors aren’t reported at the expected place.
I’ve done a few releases of jslint4java whilst this blog has been down. We’re presently at 1.4.6. It’s mostly been bug fixes and JSLint upgrades.
- The hudson violations plugin can display JSLint errors in your project. You still have to arrange to run jslint4java as part of your build though.
- Want to run JSLint inside Emacs? Have a look at this gist.
- Do you use gradle for your builds? kellyrob99 has produced a gradle-jslint-plugin.
- Want to run JSLint automatically when using mercurial? Take a look at Running JSLint as Mercurial precommit hook.
- Check out Integrating JSLint more tightly into NetBeans.
- Whilst there’s a jslint4java maven plugin in the works, this stackoverflow post describes several ways of integrating JSLint with Maven.
- If you’re doing Phonegap development, the latest version of the eclipse plugin comes with JSLint.
If you develop an open source project, then you really should set up a google alert for its name. You will be surprised.
What’s coming up?
- Update to the latest JSLint (as always). Doug Crockford recently did a major rewrite. I think I’ve got that mostly integrated now, but not released.
- There are a few outstanding bugs that I need to pay attention to.
- I’ve also been working on my own jslint4java-eclipse plugin, which feels nearly complete enough to release.
- Assuming I can ever figure out the integration testing, I’ll go back and finish off the jslint4java-maven-plugin.
Plenty to keep busy with!
I’ve just released a new version of jslint4java, 1.4. Most useful is probably support for JUnit output, which should make jslint easy to integrate with a continuous build system like hudson or pulse. Here’s the full set of changes:
- issue 35 : Removed embedded JUnit.
- issue 30 : Add a "report" formatter to the ant task.
- Also available on the command line with --report
- issue 37 : add a --encoding flag for specifying the encoding files on the command line.
- issue 36 : add a JUnit XML formatter.
- issue 26 : add support for .data() call in JSLINT.
- This is only available in the Java API right now.
- issue 39 : add failureproperty to the ant task.
- Use JCommander for flag processing.
- (INCOMPATIBILITY) This means that command line option parsing has changed slightly. You now have to say --indent 2 instead of --indent=2.
- (INCOMPATIBILITY) The minimum version of Java is now 6.
- Update to JSLint 2010-07-14.
- Adds options: es5, windows.
- Removes options: sidebar.
I’m really grateful to Cédric Beust for JCommander. It’s a really nice little library.
I’ve updated jslint4java again. This time, I’ve added:
- Support for the predef option, so you can specify a list of predefined global variables. I first said I’d do this over a year ago. 🙁
- Updated to JSLint 2009-11-24, which brings a new devel option. Now you can decide if
console.log(), etc are available.
Unfortunately, just after I’d committed the release, I noticed that I’ve managed to (somehow) pick up a junit dependency. I’ll set about removing that for the next release (issue 35).
Just a quick note that I’ve released jslint4java 1.3.2. There’s not a lot of news in here. The main new feature is that I added the ability to specify an external copy of jslint.js. This is quite useful if Doug Crockford introduces new features before I release a new version of jslint4java.
This release also upgrades to JSLint 2009-10-04, which sports a new maxerrs option.
Apart from that, I’m particularly grateful to both Simon Kenyon Shepard and Ryan Alberts for pointing out where my unit tests where non-portable. I really need to get hudson up and running on the games PC…
Whilst I ensure I have the latest version of JSLint for each release of jslint4java, it’s often difficult to know what’s actually changed between versions. Unfortunately, Douglas Crockford doesn’t maintain a public version control system1 (which is entirely up to him).
Nonetheless, it’s kind of useful to be able to look at a version of JSLint and say “this changed since the last version”. So, I’ve started mirroring
www.jslint.com into a git repository. I check for updates every hour.
This means you can now see how JSLint changes over time.
Now, it’s not as useful as it could be. It would be nice to tie these up to the changes that Douglas posts to the mailing list (e.g. announcing the new
.data() support). But that’s quite a bit more work.
I hope that this is beneficial to somebody.
1 It’s amazing how normal public version control has become over the years. This used to be a lot less common, which made projects a lot harder to understand.
Recently, I’ve been thinking about documentation more and more. I’ve just finished up some documentation for an internal product, which was all done using the maven-site-plugin and APT. This worked reasonably well: I get a generated website, with javadocs and a few howto pages I wrote.
But it really feels like it starts to fall apart when you get to a multimodule build. Maven does quite a few nice things for you, but you start to see some annoying glitches here. One of the first ones I came across was the url element. If you set it correctly in the root pom (e.g.
http://mycompany.com/project/) then maven automatically appends the artifactId when constructing the site for submodules. So you end up with
http://mycompany.com/project/mysubmodule/, which isn’t necessarily correct.
After thinking about this for a while, and how best to document jslint4java, I’ve come to the same realisation as Mark Pilgrim: plain old HTML works best. I’ve tried a few like Textile (yuck), Markdown (better), POD (too simple) and docbook (too complex). HTML strikes the right balance. Especially with the new HTML5 tags. And it doesn’t require any building to view it. Just hit refresh.
So how to make it part of the maven build? Easy. Stuff it into it’s own submodule. Then, it can be referenced by the assembly plugin later and put in the correct place in your distribution. Check out jslint4java-docs for details. It would be nice if maven natively supported zip packaging, but that’s easily overcome.
This does mean it doesn’t get automatically deployed to a server. But that doesn’t really matter. It happens infrequently enough that I’m happy to do that by hand where needed. Or at least find a better solution when I get bored of that. 🙂