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
In those threads Phil points out that the Maven-2 sites need to look
the same as the current Commons sites.
There are a couple of sandbox components using Maven-2 sites as a test
- csv is one; but the css isn't right yet. Dennis (I think) talked
about needing a commons skin for Maven-2.
> 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?
Windows XP can do zip and not tar.gz right? [without extra software].
And irritatingly, many Linux servers can do tar.gz and not zip.
Anyway, we produce both as the others have said.
> 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?
We try very hard nowadays to make sure our versioning is correct. A
minor release should have backwards compat - though I'm personally
happy with things being removed if their existence is considered a bug
(ie: 5).
Might be that we need to call this 2.0. In that case, we might want to
consider more API change - ie: removal of DefaultFileItem (?).
> 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
This is a failing in Checkstyle I think. At this point the tail is
wagging the dog, so I'm +1 to ignoring these. Niall has a good point
that the noise of all the ignored Javadoc issues hides the important
things - but it's checkstyle not pmd/findbugs and you can still sift
through noise.
- 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.)
Many +1s on the tabs. Trailing blanks are unnecessary, so no reason
not to remove them.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
