> -----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? 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.) 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
