On 11/26/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
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?
All Commons components are released with both .zip and .tar.gz files. I don't see a reason to change that now. And yes, I believe there are people who either don't have tools to explode .tar.gz files or don't know that they have such tools.
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?
The current vote is on the distributables referenced in the VOTE message that started this thread. Any changes made to the source tree since that vote was started do _not_ affect this vote thread in any way. Once a new set of distributables is created, and a new vote thread started, people can vote differently from how they did on the current distributables, but vote threads don't ever reference moving targets.
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?
Of course it is. These changes are incompatible in that some people's code will no longer compile against the new version. The API contract has been broken. Further, the changes were not preceded by deprecations, so people who don't follow ongoing development will suddenly find their code broken, rather than having had advance warning through deprecations. Perhaps if this was a major version upgrade, this _might_ be acceptable, but it's certainly not acceptable for a minor version upgrade, at least here at Jakarta Commons.
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.
I'm sorry, but I find your attitude quite disturbing here. You come in on a project that has been very close to Checkstyle-clean for years, you make changes that introduce hundreds of new violations, and you have the gall to say that you refuse to fix the ones you don't agree with? That's not how we work here at Commons either. -- Martin Cooper 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]
