On 9 January 2011 08:14, Karl Wright <daddy...@gmail.com> wrote: >> I still think the binary archive is unnecessarily bloated, and will >> cause wasted load and resources for mirrors and consumers. >> > > If it were straightforward, I would already have done it. > > Here's a rundown of the space usage in the dist directory of the -bin object: > > doc: > 995 File(s) 37,349,684 bytes > example: > 64 File(s) 55,753,928 bytes > processes: > 42 File(s) 13,610,369 bytes > web: > 3 File(s) 37,917,103 bytes > lib: > 10 File(s) 1,400,982 bytes > > The "doc" area includes Forrest generated html and pdf, along with Javadoc. > > As I stated before, there is two of everything, because there is a > binary area set up for multiprocess execution, and a second one set up > for single-process. The single-process one is entirely encapsulated > under "example" above. The multiprocess one is spread among > "processes", "web", and "lib". > > The "web" part consists of three .war files that are part of > ManifoldCF. Each of them is of significant size, 12M, because they > are set up to be potentially deployed independently. The same .war > files are present in the "example" single-process setup, although the > dependent jars within are not used there because it is single-process. > > (1) The biggest possible help would be to have both a single-process > target and a multi-process target, and only ship the single-process > example. Savings: about 55M. Downside: Minor changes to the > "how-to-build-and-deploy" documentation, and no multi-process binaries > shipped. But, if we ask people to build their own multi-process > deployment, that then begs the question, why are we shipping ANY > binaries at all? They could just as readily build the single-process > version too. > > (2) Second biggest: build separate single-process and multi-process > war targets. This would introduce, however, a dual target throughout > every level of the build system - doubling the complexity as I > explained. Luckily, this would NOT extend to connector builds. > Potential savings: about 36M. > > (3) The change you proposed, copying dependent jars into place after > download, depends on the size of the dependent jars and where they > wind up. The size of jars which come from dependencies: > 38 File(s) 13,604,879 bytes > As I said, there are two open copies of these, one for the
Not sure what you mean by "open" copy. There are also 2 copies of each of the war files, total 37M for one set. > single-process and one for the multi-process. This option would also > increase build complexity considerably, because all the test and doc > targets rely on the multi-process jars to be in place, and also would > require me to rework the "how-to-build-and-deploy" documentation > significantly, as well as end-user complexity. Total possible > savings: 27M, or 13M if (1) were adopted above. Sorry, but I still don't understand the complexity argument. Here's what I am suggesting: 1) Ship the archive with one copy of each distinct jar or war. (*) 2) Add a new (independent) target (e.g. "install") to the build file which creates the necessary duplicates. (or create a new build file) 3) Update the README to tell users to run the Ant "install" target once after download. Once the Ant "install" target has been run, it is as if the archive had contained the copies in the first place, so everything will work as before. (*) This would give a total saving of 27+37 = 64MB, which is about 40% of the total download currently - well worth saving, IMO. Have I missed anything vital? > (4) Grant suggested that we simply not include the PDF portion of the > doc build. This has the disadvantage of causing each site page to > have a broken link, but otherwise the PDFs are not of great value, > excepting perhaps the end-user documentation PDF. Savings: about 10M. > > My proposed solution, which was to ship only built documentation (for > ease of bootstrapping) and allow everyone to build their own binaries, > was disliked by Grant. So basically we're now in a position of > choosing half a loaf and arguing over what half. Unfortunately this > is not a technical decision - it is a political one. So please make > your preferences known, and ideally you and Grant can have it out over > the right way to slice the loaf. > > Thanks, > Karl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
