Today, I’m happy to announce the availability of annotation-based mounting and merging of resources in wicketstuff-merged-resources (version 3.0-SNAPSHOT for Wicket 1.4, version 2.1-SNAPSHOT for Wicket 1.3). In order to mount resources, all that’s needed is adding annotations to component classes:

The example above mounts and merges PanelOne.js (default is simple name of class + “.js”) into all.js (another default) and PanelOne-print.css into print.css which will be included with scope print. Additionally, accept.png will be mounted to /img/accept.png (as path starts with a ‘/’) which makes it easy to use from css files.

There’s not much left for this to work. All it takes is a single method call in your Application’s init code:

In this example, all components in package com.example.components (including sub-packages) will be scanned for annotations. If not defined otherwise, all resources will be merged into single files for JS (/files/all.js) and all CSS media types (/files/all.css, /files/screen.css, /files/print.css, …).

As an added benefit, you’ll get all the other features of wicketstuff-merged-resources:

merging of multiple files into one for less HTTP requests

adding of versions to resource paths for aggressive caching

pre-processing of resources (e.g. replacing colors in CSS files)

optionally uploading them to Amazon Cloudfront (well, at least you can expect this feature soon – we are using it already)

So you will speed up rendering of your pages while simplifying and reducing your code (there’s no need to merge, mount or add HeaderContributors manually anymore)!

(This new feature is mainly based on the idea and code of Jörn Zaefferer – Tanks!)

well, actually I planned to release 3.0 for a while. The only problem is that I’m still using 2.x (as I’m currently stuck on Wicket 1.3).

However, if you think 3.0 works and is ready for prime time, I would release it. Therefore, my idea would be that you keep developing and testing with 3.0-SNAPSHOT, but as soon as your project is ready for production, I will create a release.

First off, thanks for this package. It was exactly what I was looking for! I have everything working just fine on version 2.0. However, I keep getting serialization errors for your components. Here is a log:

I would appreciate a 3.0 release when you have the chance. I’ve only been using merged-resource on small projects, but it has held up well. I am not, however, using the annotation features, as those didn’t seem to fit my coding style.

On a related note, I wrapped your code with a simple helper class of my own that has been working well for my purposes:

@Matt I’ve just committed changes to ResourceMount inspired by your ResourceMountBuilder. Actually, I don’t really see the main benefit of using yet another builder around a builder API. It’s best to simply extend ResourceMount if you want to change it’s default behaviour. There are lots of protected methods you may override in order to change the defaults. Additionally, you may use ResourceMount#clone() to reuse configuration of a single ResourceMount for multiple mounts. However, I’ve added a new constructor (ResourceMount(boolean)) and a new method (ResourceMount#build(WebApplication)). Please have a look and tell me what you think. It’s the last change to get any suggestions into version 3.0. Lastly, I’ve used your ResourceBuilderTest as ResourceMount test. The only thing it doesn’t support like your ResourceBuilder is detection of JS and CSS files being added to the same merged resource. If you’d like to see this feature in 3.1, please crate a JIRA issue.

I think I am going to stay with my builder-wrapper approach for the time being. Extending your class is hard because if I want to add a new public method signature, I’ll need to override every single public method that returns a “this” reference to return the narrower type.

For example, if I want to add a setCssMedia() method (which as far as I can tell is something that ResourceMount does not currently support), my class will look like this:

Because setPath() is returning ResourceMount, not CssResourceMount. I’d have to override and redefine setPath() (and every other public method that returns a “this” reference) to have the CssResourceMount return signature.

So yes, I can subclass and override existing methods, but I can’t subclass to effect the public API without a lot of extra work.

Anyway, I like what I see otherwise in 3.0. Don’t let me hold you up. I’ll add JIRA issues later this week for the CSS media and CSS/JS detection enhancements.