Oh I love this idea. I am having the same issues with my application as it has assets that are GWT components and I'd like to version those separately too. Enthusiastic +1.
On Jul 13, 2012, at 1:16 PM, Kalle Korhonen <[email protected]> wrote: > We are deploying our app to production once a week and I find it quite > annoying that every time we basically force our users to re-download > all of the application resources even though only a small subset of > them changed, causing wasted bandwidth and perceived performance > issues. At the same time, we cannot afford users to have stale > resources in their caches. All of the Tynamo.org modules add their own > version to asset paths so adding the application version is completely > redundant, for example: > http://localhost:8080/assets/0.0.1-SNAPSHOT-1341940822046/facebook-0.1.0/components/fb-button.css > > We briefly looked into generically changing how asset paths are > constructed to include module's own version but it's difficult to > achieve because the context (from which module the asset came) is > lost. > > Tynamo modules contribute something like: > public static void > contributeClasspathAssetAliasManager(MappedConfiguration<String, > String> configuration) > { > configuration.add(PATH_PREFIX + "-" + version, "org/tynamo/security"); > } > > What if we implemented a ClassPathAssetAliasManager2 that would take a > MappedConfiguration<String, Package> so we could automatically do the > same as above for add-on modules, using > Package.getImplementationVersion()? > > It would encourage the (best) practice of placing the main module > class to the intended root package of a module, and it'd be very > simple to contribute in the module like so: > public static void > contributeClasspathAssetAliasManager2(MappedConfiguration<String, > Package> configuration) > { > configuration.add(PATH_PREFIX, getClass().getPackage() ); > } > > Similarly, LibraryMapping (a contribution to ComponentClassResolver) > could also accept a Package, rather than just a string. > > What do you think? > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
