On Fri, Nov 19, 2010 at 7:14 PM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: >> -----Original Message----- >> From: Daniel F. Savarese [mailto:d...@savarese.org] >> Sent: Friday, November 19, 2010 10:50 >> To: Commons Developers List >> Subject: Re: [VOTE] Release Commons NET 2.2 based on RC3 >> >> >> In message <02aa127cd8dcde48bc7d2dfb6c87083a07dda...@nwt-s- >> mbx2.rocketsoftware. >> com>, Gary Gregory writes: >> >I do not think we should base decisions like this on a byte count, relative= >> > or not. I like to think of what users do with this stuff. >> >> To be clear, the reason for removing the extra jars from commons-net was >> that their inclusion did not appear to have been purposeful, having been >> picked up by a *.jar filter that would pick up any new .jar artifacts that >> happened to be built. I had no idea the extra jars were being included >> and neither did sebb. Comments about bloat were secondary in addition to >> the primary goal of wanting to correct what appeared to be an unintentional >> accident. >> >> That said, at no time do I recall any commons-net user make a request >> for including additional artifacts, specifically source code, in the >> binary distribution. Does anyone involved in this thread actually >> use commons-net and the javadoc/source jars in its binary distribution? > > <minorRant> > I use 9 [commons] components (but not [net] directly) and IMO all should do > the same thing. It's maddening that [commons] is one project but all of its > components spin their wheels about artifact id's, package names with or > without versions, what file is in what distro, etc. Yes, I understand we are > a volunteer-based organization and people want to do what they want to do. > But still, some consistency goes a long way. > </minorRant> > > <tangent> > I'd love to be able to use a commons-all.jar even if I only directly use half > the components. > </tangent> > >> >> Setting aside that the extra jars are available via the maven repository >> for anyone who needs them, if it's important to include javadoc and >> source jars, the only thing that makes any sense to me is to include the >> javadoc jar in the binary distribution and omit an extracted documentation >> tree. Every Java developer, using an IDE or not, knows how to run >> jar -x to extract the javadocs (of course, they should also know how to >> create a jar). >> >> The source jar can go in the source distribution, omitting the >> extracted directory tree already contained in the jar. In general, >> when you download a binary distribution you do not expect for it >> to include source code. Likewise, when you download source code, >> you don't expect it to include binaries. I do not think it is >> unreasonable for someone who wants both binaries and source code to >> download both the binary and source distributions. If the world is >> such that people expect source code to be present in a binary >> distribution, then I capitulate. > > I think we need to look at user stories to guide this decision. I see three: > > (1) Drop-in the latest and greatest. > I want to replace a previous version: I download the bin zip, unzip it and > drop in the jar. > > (2) Development > I am an API user. Seeing the source is key for debugging and otherwise > informative, including seeing the Javadoc. I download the bin zip, unzip it > and drop the jar in my IDE. I tell the IDE to match the bin jar with the src > jar. > > (3) Custom build > I want to make a custom build so I download the src zip and hack away. > > In all these cases, I download one zip file. Why make it harder?
+1 Niall > Thoughts? > > Side note: I never use the javadoc jar. > > Perhaps this argues for three distros: bin, ide, and src. This uses even more > bandwidth. In the quest for simplicity, we can go the other way and only > provide ONE all in one distro (my preference.) > No please 2 distros is enough. Niall > Gary > >> This is not a big deal other than >> in the hypothetical case where a sufficient number of projects add >> redundant artifacts to distributions so that all those extra bytes >> consume excessive bandwidth when mirrors pull from the ASF. A number >> of years ago we were advised by infrastructure to remove old releases >> to reduce bandwidth consumption when mirrors pulled. Halving the >> size of the binary release would be consistent with that overall goal. >> >> The above is merely my opinion, not a call to action. This matter >> isn't worth the time expended so far on it, so whatever ends up >> happening is fine by me. However, let's please avoid indirectly >> denigrating remarks. I didn't "start a mess." All I did was vote >> on a release. How others react is not my doing. >> >> daniel >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
