Return-Path: Delivered-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Received: (qmail 71422 invoked from network); 13 Jan 2010 17:43:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Jan 2010 17:43:06 -0000 Received: (qmail 87746 invoked by uid 500); 13 Jan 2010 17:43:06 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 87718 invoked by uid 500); 13 Jan 2010 17:43:06 -0000 Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mime4j-dev@james.apache.org Delivered-To: mailing list mime4j-dev@james.apache.org Received: (qmail 87708 invoked by uid 99); 13 Jan 2010 17:43:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jan 2010 17:43:06 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of apache@bago.org designates 209.85.220.212 as permitted sender) Received: from [209.85.220.212] (HELO mail-fx0-f212.google.com) (209.85.220.212) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jan 2010 17:42:56 +0000 Received: by fxm4 with SMTP id 4so20197189fxm.12 for ; Wed, 13 Jan 2010 09:42:36 -0800 (PST) Received: by 10.223.14.140 with SMTP id g12mr11932105faa.50.1263404555715; Wed, 13 Jan 2010 09:42:35 -0800 (PST) Received: from mail-fx0-f212.google.com ([72.14.240.161]) by mx.google.com with ESMTPS id g28sm7503572fkg.38.2010.01.13.09.42.35 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 09:42:35 -0800 (PST) Received: by fxm4 with SMTP id 4so20197159fxm.12 for ; Wed, 13 Jan 2010 09:42:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.141 with SMTP id c13mr455307wef.66.1263404554293; Wed, 13 Jan 2010 09:42:34 -0800 (PST) X-Originating-IP: [78.134.13.12] In-Reply-To: <1262968925.12096.14.camel@ubuntu> References: <9426afb71001051133g3f4a065bsb7058cc6e2ce09dd@mail.gmail.com> <1262871132.5718.21.camel@ubuntu> <9426afb71001070554v2d19c0b0he0dc3971fb306c1a@mail.gmail.com> <1262873631.5718.28.camel@ubuntu> <9426afb71001070632ia5dcdd7idf0fcd75a07f475e@mail.gmail.com> <1262878002.5718.40.camel@ubuntu> <9426afb71001070745l2ad36796vc6efdbe70adbaa4d@mail.gmail.com> <1262944734.12096.4.camel@ubuntu> <9426afb71001080219y2a111209rfcca2978606dc973@mail.gmail.com> <1262968925.12096.14.camel@ubuntu> Date: Wed, 13 Jan 2010 18:42:34 +0100 Message-ID: <9426afb71001130942l16680542y1f12ac2414efc7b9@mail.gmail.com> Subject: Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions From: Stefano Bagnara To: mime4j-dev Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 2010/1/8 Oleg Kalnichevski : > With so many classes moved to different packages an iterative merge > would just be too hard. I am +1 to merging the entire branch down to > trunk. Remaining issues can be dealt with once the branch has been > merged. > > Minor stuff: > > (1) I also would like to propose a few minor changes / renames. Ideally, > I would like the 'steam' package to be fully usable out of the box. So, > it would be good if DefaultBodyDescriptor was moved to 'steam' and > renamed to BasicBodyDescriptor for consistency. I also think > FullBodyDescriptor is a better name for MaximalBodyDescriptor I moved the DefaultBodyDescriptor, and also some method from MimeTokenStream to BasicTokenStream. I'd like to leave the Maximal to Full change for a later step (after merge), but I agree that "Maximal" is not a good name. > (2) I have a number of test cases failing on me when run on Windows. I > think mismatch in line delimiters is the cause. I would be great to have > this fixed before the merge. All test cases used to work on Windows. I double checked this with a new checkout (windows and freebsd) and it worked. I guess this is because you have old resources already checked out and they differs from real resources only for newlines so svn is not correclty updating them. Can you check this on a clean checkout? Can you tell me a specific test that doesn't work (and maybe send me a zip with the original and expected test files so I can bit-compare them with mine?) ? > (3) Tons of javadocs need to be reviewed / updated. I am willing to > help. Maybe we can fix them once we agree that the branch is to be merged. We had no comments from Markus and last comment from Robert was "I will veto any merge attempt".. so I'd like to wait some day to see if they will take into consideration reviewing the code. Stefano