For what it is worth, there is still discussion on general.i.a.o about the size of our binary artifact. I don't think it will block release since there are plenty of people who think it's just fine. Still, my response to that concern and a specific proposal is below. I would very much like to get the community's sense of where we think we should split the loaf - if we think we should at all.
Thanks, Karl ---------- Forwarded message ---------- From: Karl Wright <daddy...@gmail.com> Date: Sun, Jan 9, 2011 at 3:14 AM Subject: Re: [VOTE] Release Apache ManifoldCF 0.1 To: gene...@incubator.apache.org > 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 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. (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