I know you have raised this issue before, but I think it is preferable to leave them as is. Pivot-based server-side apps will use pivot-core.jar and pivot-web.server.jar, but not the others. Client-side apps will almost certainly use pivot-core.jar, pivot-wtk.jar, and pivot-wtk.terra.jar; they will probably but not necessarily use pivot-web.jar; they may use pivot-charts.jar. The current modularity allows developers to choose which libraries to include, and the performance penalty of one or two additional HTTP requests is negligible, IMO.
Of course, you are welcome to re-package the classes any way that makes sense for you. It's not terribly difficult to rebuild them from source, or unzip/reassemble the existing binaries. I just don't think a monolithic JAR is a use case we want to cater to. On Friday, March 27, 2009, at 07:13PM, "Sandro Martini" <[email protected]> wrote: >Hi, >what do you think on adding a single jar generation in the build >process, as an optional task that could be useful in some cases (lazy >programmers/users, etc :-) ), so instead of the 4 base jar, only one >like pivot.jar, or pivot-1.1.jar ? > >Standard use cases requires (in most cases) all the base 4 jars >(leaving the pivot-charts and other skins) and maybe not the terra >skin ... and joining all them in one could help also to minimize http >queries, and the single jar could be compressed as .pack.gz to reduce >all the overhead. > >Ok, this is a little convenience question (from our client-side users >point-of-view), i know ... to finish today discussions on jars. > >Thanks and bye, >Sandro > >
