I'm in the process of creating my own wro4j plugin for SBT as my project has some special requirements not achievable with xsbt-wro4j-plugin directly.
I checked the source code of xsbt-wro4j-plugin (here) and also the wro4j API documentation to gain some insight into the file creating process but I'm a bit puzzled here. As far as I can tell the plugin uses Mockito to produce the necessary resources somehow but I don't get how it cooperates with wro4j itself. If I'm right this whole Mockito stuff is a hack so we can use SBT's caching mechanism.
Question #1 is whether we can avoid this Mockito voodoo without losing caching support.
Question #2: what is responsible for file creation within wro4j? Could I override it?
This is not necessarily an answer for all of your questions, but an explanation for the reason xsbt wro4j plugin (and wro4j-maven-plugin) uses mockito.
The wro4j was created initially as a runtime solution only (using HttpServletFilter) to minimize static resources on the fly. As result, the internal API is based on servlet-api (more specifically HttpServletRequest & HttpServletResponse objects). Later, when a build-time solution was required, instead of changing the internals of the framework, a suitable workaround was applied: using a mechanism for stubbing servlet-api in a non servlet environment (build-time).
The way I see the long term approach: is to make wro4j, servlet-api agnostic and allow build-time solutions like maven plugin or xsbt plugin, to not require using this workaround. Unfortunately, in order to do that, the internals of the wro4j should be changed and that would require a major release (incompatible with previous versions). Given the amount of work required to do that, most probably this will be delayed.