On Fri, Jul 13, 2012 at 11:36 AM, Howard Lewis Ship <[email protected]> wrote: > 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.
A lot of work for the library developer, right? For the user, it should be the same. If we did it as I outlined and possibly even contribute it on behalf of the library when it's loaded, what's the harm? Almost every library has it's ImplementationVersion set in the manifest. I'm barely thinking of Javascript here. Images and other media formats, even if small will quickly add up to the overall weight if they need to be needlessly re-downloaded every time. I couldn't follow your thought on "this is for two reasons - security - ability to enumerate..." What's this referring to? How's this relevant to security? What I love about Tapestry is that even if something's not implemented I can usually get it done the way I want to by overriding a few services without disturbing anybody else. However, this is one of those things were I really dislike how it works and currently there's no way to resolve it to my satisfaction. It's one thing to deploy once a week, but imagine if we were deploying ten times a day - the costs would add up very quickly and it's all unnecessary. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
