> -----Original Message----- > From: Oliver Heger [mailto:oliver.he...@oliver-heger.de] > Sent: Friday, November 19, 2010 12:17 > To: Commons Developers List > Subject: Re: [VOTE] Release Commons NET 2.2 based on RC3 > > Am 19.11.2010 19:50, schrieb Daniel F. Savarese: > > > > 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? > > > > 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. 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 > > > > > Just a comment from me because my remark somehow started the whole > discussion: > > As I pointed out with my +1 vote I do not see the lack of these jars as > a blocker. > > However, I was a bit surprised that they were missing as it seems to be > a de-facto standard for commons components. I remember that at my first > attempts as release manager for [configuration] I was asked to add those > jars. Also, we even had discussions about the content of the manifest > files in them. > > Personally, I do not need these jars because maven can download them > automatically and install them in an IDE. AFAIK, Eclipse supports > attaching both source code and Javadocs attachments to a library. So for > some users they might actually be beneficial. > > As others pointed out in this thread, a common strategy for all commons > components would certainly be good.
+1! Pretty please. Gary > > Oliver > > --------------------------------------------------------------------- > 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
