Building your project with Jasmine

mvn package

Executing any Maven lifecycle phase after prepare-package will show off everything this plugin has to offer. However, the results will only be useful once you've added some Jasmine specs and JavaScript. Details follow:

src/main/javascript

By default, the plugin expects to find your JavaScript sources (i.e. ninja.js) and dependencies (i.e. lib/prototype.js) in src/main/javascript. However, for most
existing projects, it will make more sense to specify where your JS sources are in (usually somewhere in src/main/webapp) and remove the packageResource goal (see "Supporting WTP" below for an example).

src/test/javascript

Store your Jasmine specs (i.e. ninjaSpec.js) in src/test/javascript. No need to create an HTML spec runner, one will be generated and executed for you by the jasmine:test goal!

Example test Output

jasmine-maven-plugin behaves just like maven-surefire-plugin and will fail the build on spec failures (unless haltOnFailure is set to false).

Usage Notes

Project layout

The jasmine-maven-plugin presumes a default project directory layout. If this layout doesn't suit your project, fear not, as it's entirely customizable. In adition to everything documented here,
you can check the documented source of the base Mojo class to see which properties have been
parameterized.

As seen above, by default, the plugin looks for JavaScript placed in src/main/javascript, while test specs are each in src/test/javascript. The plugin supports nested directories and will maintain your directory structure as it processes the source directories.

Goals

jasmine:resources

This goal binds to the process-resources phase and copies the src/main/javascript directory into target/jasmine/src.
It can be changed by configuring a parameter named jsSrcDir in the plugin execution section of the POM.

jasmine:testResources

This goal binds to the process-test-resources phase and copies the src/test/javascript directory into target/jasmine/spec.
It can be changed by configuring a parameter named jsTestSrcDir in the plugin execution section of the POM.

jasmine:test

This goal binds to the test phase and generates a Jasmine runner file in target/jasmine/SpecRunner.html based on the sources processed by the previous two goals and Jasmine's own dependencies.
It will respect the skipTests property, and will not halt processing if haltOnFailure is set to false.

jasmine:preparePackage

This goal binds to the prepare-package phase and copies the production JavaScript sources from target/jasmine/src to /js within the package directory (e.g. target/your-webapp/js).
The sub-path can be cleared or changed by setting the packageJavaScriptPath property

jasmine:generateManualRunner

This goal binds to the generate-test-sources phase and will generate an extra spec runner HTML (named ManualSpecRunner.html by default) in the jasmine target directory (target/jasmine).
This way, you can easily run your specs in the browser as you develop them, while still leaning on the plugin to keep the HTML up-to-date for you. Note that this HTML file is separate from
the one generated during jasmine:test, because it points to the source directories directly.

When using the manual runner in a browser, be careful to edit your source & specs in the project's src directory, even though the runner itself runs in target!

You can run the plugin with all five goals or fewer, if you choose. For instance, if you run your application in Eclipse WTP and you want to keep your production
JavaScript in src/main/webapp to facilitate easier iterative development, you could skip the preparePackage goal and configure the jsSrcDir property to point
at src/main/webapp/[your-js-directory] instead.

Enforcing the order in which JavaScript files are loaded

You can configure the plugin to load a list of JavaScript sources before any others. This is particularly useful when your scripts or specs must be loaded in a particular order
to work correctly.

So if you wanted to make sure jQuery was loaded before your application's scripts, and that the terrific jasmine-jquery was
loaded before your specs, and you wanted to load Prototype from Google CDN (which isn't even stored in your project), your POM would look like this:

JUnit XML Reports

The plugin's test goal will output the test results in a JUnit text XML report, located in target/jasmine/TEST-jasmine.xml. The implementation attempts to satisfy the most middle-of-the-road consensus as to what the schema-less XML report "should" look like.

As an example, to integrate the report into a Hudson job (note that it must be a freestyle job), select "Publish JUnit test result report" among the available "Post-build Actions" and include a file pattern like "**/jasmine/TEST*.xml". Once included, your jasmine specs will be counted and interactive in the same way your other tests are!

Specifying which Browser to execute Jasmine specs with

By default, the plugin will execute the project's specs using HtmlUnit's "FIREFOX_3" BrowserVersion.
If you'd like to execute your specs against a different one of its profiles, you can specify it in the plugin's configuration in your POM.
HtmlUnit currently only offers a few flavors of FireFox and IE (see its JavaDoc for the exact names),
but here is an example configuration specifying that specs should be executed against HtmlUnit's IE6 profile:

Current Version Info

The plugin's version numbering will mirror the version of Jasmine that backs it. The latest version of the plugin points to Jasmine 1.0.1, so its version number is 1.0.1-SNAPSHOT.
If you need a non-snapshot release (say, to satisify the maven-release-plugin), you may use 1.0.1-beta-6.