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.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
