Fwd: Incubator email about artifact's size

[Karl Wright <da...@gmail.com>]

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 <da...@gmail.com>
Date: Sun, Jan 9, 2011 at 3:14 AM
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general@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