Earlier versions of Tapestry tried to track versions of each library separately; you had to contribute a LibraryMapping to ComponentClassResourceResolver, and contribute a seperate value to ClasspathAssetAliasManager that included your version number. That was a lot of work and was error prone, which is why 5.2 switched to the one-version-number-to-rule-them-all.
The upcoming module stuff will make version numbers even more important. I don't see a viable middle ground currently, though that's short of saying it is impossible. Perhaps there's a way that we could define an optional library version number, that would default to the application version number. On the other hand, I expect that 5.4 will be much "lighter" in its use of JavaScript as the use of stand-alone libraries & stacks will start to switch over to modules, which are loaded in parallel and as needed. By 5.5, stacks and libraries should be the rare exception, and modules the main approach. I'm still working on many of the details, including whether and how to aggregate modules into stacks for efficient preloading. As a side note, I expect that by 5.5 we'll require that all classpath assets made visible to the user be moved from the main class path to folders under META-INF/assets. I.e., "com/example/foolib/components/MyLib.js". I'm not quite sure what the folder structure will be; possibly just parallel packages, just rooted under META-INF/assets/ instead of /. On Fri, Jul 13, 2012 at 11:17 AM, Thiago H de Paula Figueiredo <[email protected]> wrote: > Sounds good to me. > > >> >> >> >> 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] >> > > > -- > Thiago H. de Paula Figueiredo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
