incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: [VOTE] Release Apache ManifoldCF 0.1
Date Sun, 09 Jan 2011 08:14:54 GMT
> 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:

             995 File(s)     37,349,684 bytes
              64 File(s)     55,753,928 bytes
              42 File(s)     13,610,369 bytes
               3 File(s)     37,917,103 bytes
              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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message