commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [VOTE] Release Commons NET 2.2 based on RC3
Date Fri, 19 Nov 2010 20:19:34 GMT
> -----Original Message-----
> From: Oliver Heger []
> 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<02AA127CD8DCDE48BC7D2DFB6C87083A07DDA909@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.

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

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

View raw message