Hi, Niall,
On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
I would have preferred the release be cut using maven1 rather than m2.
The maven1 build is tried and tested and the gripes of those of us
that checked out previous releases have been fixed in the maven1
build. I guess that doesn't matter if the release is up to scratch but
would be interested to know if others think we're ready for releases
using m2 yet?
See for example
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2
http://marc.theaimsgroup.com/?t=115719054100004
The first issue I have with checking out this RC is that you've only
posted the "tar.gz" source and binary distros. I would have liked to
see the full set - zip versions and md5 checksums (the maven1 build
for fileupload creates the md5 checksums for you).
Are you actually going to tell me, that this is an issue? (The archive
type, not the checksum, which must of course, be added to
distributables. As are .sha1 and .asc files, btw.) If so, changing it
is as simple as adding one line to the assembly descriptor. But who do
you believe is unable to use tar.gz in 2006?
I think there are three serious issues with this RC:
1) It doesn't comply with the new "ASF Source Header and Copyright
Notice Policy":
http://www.apache.org/legal/src-headers.html
I wasn't aware of a change in policy. You are right, that must be
honoured. However, you already did it, so it cannot be counted as a
reason for a -1, right?
2) According to the jar's manifest file its been built using JDK
1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a
release would make me nervous - but using a RC version of Java to cut
the fileupload release is bad news IMO.
Ok, I'll keep that in mind for the next approach.
3) The clirr report you produced: which shows the following
incompatibilities with the previous fileupload version:
1) FileUploadBase - public constant MAX_HEADER_SIZE removed.
2) FileUploadBase - protected method createItem removed
3) FileUploadBase - two public constructors for
SizeLimitExceededException removed
4) FileUploadBase - public static class UnknownSizeException removed
5) MulitpartStream - gone from public to package visibility
1) A maximum header size no longer exists. See FILEUPLOAD-108.
2)+5) See
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114988352104258&w=2
4) This exception can no longer be thrown, because content-length=-1
is allowed now.
All in all, do you really think that's as big an issue as you make it?
One thing thats disappointing is that the last fileupload release had
only 5 checkstyle issues. This one has 376 of which 200 are for tab
characters which I personally dislike in source.
The reason is, IMO, that checkstyle is quite outdated. Examples:
- Why should I add a comment to a field called serialalversionuid?
- Why should I add a comment to an implementation or overwritten
superclass method, when I know that the doclet will simply copy
the interface or
- It's ridiculous to require comments for private fields, even if they are
simply storage for getters and setters.
- What's the problem with trailing blanks? (I can understand your
sentiment against tabs, btw.)
Please note, that I have enabled almost any warning that Eclipse
can trigger. And, believe me, these are more and more serious matters
than checkstyle detects. Nevertheless, I have eliminated almost all
warnings today, except those I cannot omit and I refuse to remove,
because I know better than checkstyle that it makes sense to keep
them. The code I have added contains *no* Eclipse warning. Elder
code does.
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
