Ray Greenwell
8acb1ee6dd
Part 1: the unification. Two things actually: - If there are auxiliary groups, the resources from all groups were downloaded all together, but patched individually. So each patcher would restart the progress bar from 0-100%. Created a unified progress observer that merely gives each patching phase an even division of the percentage. - I enumerated the major steps involved in getting down, and assigned a completely arbitrary max progress percentage to each. All percent progress reports are now bounded to the range of the max for the current step and previous step's max reported progress. Backwards progress is ignored, so if getdown goes back and re-does some steps the bar may "stall". If a step is skipped, the progress bar doesn't jump ahead, rather it will use the range of any skipped steps to more fully report the 0-100% progress of the current step. I'm going to try this out and make adjustments. This feature isn't done, part 2 is moving any time estimate up to the "status" label (instead of the "progress" label).
What is it? ----------- Getdown (yes, it's the funky stuff) aims to provide a system for downloading and installing a collection of files on a user's machine and upgrading those files as needed. Though just any collection of files would do, Getdown is mainly intended for the distribution and maintenance of the collection of files that make up an application. See the Google Code project for documentation and other information: http://code.google.com/p/getdown Building -------- Getdown is built with Maven in the standard ways. Invoke the following commands, for fun and profit: % mvn compile # builds the classes % mvn test # builds and runs the unit tests % mvn package # builds and creates jar file % mvn install # builds, jars and installs in your local Maven repository