> It's unacceptable to not release software according to Apache guidelines. > There's some flexibility in those guidelines (whether to include a binary > release or not, whether to include jar files in a distro or use Maven, etc.), > and then there's not (must include a source release; must have a KEYS file; > etc.etc.) >
I'm not arguing; I've accepted the conclusion that there will be no binary distribution. >> >> The three copies of the dependent jars occur because of the following: >> >> - There is one copy of the jar that is used by the build >> - There are two distinct execution environments, one single-process, >> and one multi-process, that are built >> - Each execution environment has its own subtree that it executes from > > Are all of these Jars simply copies of an original Jar, or are they > separately licensed? > It's all the same license. The dependent jars are copied into the appropriate target locations by the build process. So without the build, you have one copy of each dependent jar. >> >> If the built environments are no longer distributed, then there will >> be one copy of each dependent jar included. I'm leaning towards just >> having this minimum distribution since size is apparently a huge issue >> here. > > It's a huge issue everywhere. Your release will be mirrored around the world > using Apache's mirroring system. Beyond that it will be likely replicated N > times at M companies who are using it. Size *is* a big issue, not just *here*. This was not obvious to me in the era of 1Tb disks costing $50. Builds of this size have not been considered problematic in any place I've worked for at least a decade. But I will accept your restrictions. > > Eh, either way is fine with me, and I don't think anyone here should > legislate on this. It should be a ManifoldCF community decision IMHO. > If you are flexible, I will recommend we include the built docs. It will increase the size of the distribution somewhat (from 32M to 45M per tar.gz/zip), but it gives the user much more environmental flexibility. Karl --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
