Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (nike.apache.org: domain of markus.wiederkehr@gmail.com
 designates 209.85.220.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=mYrkHRzsR4FpDhSyPLhGhBJcVNQAcmbyomiGcmPoy5P8Ycx7SX2JvFHEbBXb+TEScd
         0GFwV+UTlL/D/wblKTvl/+DdLkSviA3QupSzwirDO2SqErUKeg4j5gBBxy7Jmnz8pb3J
         mFl6QA7ML4vfDUHHzuLt1AYwlzKfldG9cygNw=
MIME-Version: 1.0
In-Reply-To: <9426afb71001130942l16680542y1f12ac2414efc7b9@mail.gmail.com>
References: <9426afb71001051133g3f4a065bsb7058cc6e2ce09dd@mail.gmail.com>
	 <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>
	 <9426afb71001130942l16680542y1f12ac2414efc7b9@mail.gmail.com>
Date: Wed, 13 Jan 2010 23:32:16 +0100
Message-ID: <a92573961001131432ja5b6258qdc355f974b2a0e47@mail.gmail.com>
Subject: Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch
	review and questions
From: Markus Wiederkehr <markus.wiederkehr@gmail.com>
To: mime4j-dev@james.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 13, 2010 at 6:42 PM, Stefano Bagnara <apache@bago.org> wrote:
> 2010/1/8 Oleg Kalnichevski <olegk@apache.org>:
>> 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.

Hi Stefano,

Mime4j is not very much on top of my personal priorities right now
(sorry) but I will try to look into your proposed code changes in the
next couple of days.

Without having looked into the code I would tend to trust you and Oleg
to come up with a good solution and a better Mime4j than what we have
now.

By the way, I think there were no commits to trunk after you started
your branch. So once consensus is reached it would be possible to "svn
rm trunk" and "svn mv cycleclean trunk".

The result would be the same as if all development happened in trunk
so I think in this case there is no reason to veto a merge only
because it's a merge.

Cheers,
Markus