Field / Address model refactoring; was Re: 0.6.2 or 0.7 any time soon?

[Oleg Kalnichevski <ol...@apache.org>]

...

> Why can't you simply work on trunk or on a branch here in our svn? I
> think I encouraged you multiple times to simply do this, I don't
> really understand why you aswer me like I'm trying to stop you.
> My preference is for you to use trunk. We use CTR, so go ahead and I
> hope you will be happy if I review what you do.


Stefano et al

I committed the first round of (potentially less contentious) changes to
the DOM API refactoring branch [1]. Please review and let me know if you
can live with these changes. The main difference with the current trunk
is that address formatting code was factored out into a separate utility
class akin AddressBuilder and MailboxImpl / GroupImpl classes were made
unnecessary. 

If there are no vocal objections to these changes, I would like to merge
them down to trunk and proceed with potentially more inflammatory
changes to MessageImpl, HeaderImpl, and friends.

Oleg 

[1]
https://svn.apache.org/repos/asf/james/mime4j/branches/dom-api-refactoring

Re: Field / Address model refactoring; was Re: 0.6.2 or 0.7 any time soon?

[Stefano Bagnara <ap...@bago.org>]

2011/1/12 Oleg Kalnichevski <ol...@apache.org>:
> ...
>
>> Why can't you simply work on trunk or on a branch here in our svn? I
>> think I encouraged you multiple times to simply do this, I don't
>> really understand why you aswer me like I'm trying to stop you.
>> My preference is for you to use trunk. We use CTR, so go ahead and I
>> hope you will be happy if I review what you do.
>
>
> Stefano et al
>
> I committed the first round of (potentially less contentious) changes to
> the DOM API refactoring branch [1]. Please review and let me know if you
> can live with these changes. The main difference with the current trunk
> is that address formatting code was factored out into a separate utility
> class akin AddressBuilder and MailboxImpl / GroupImpl classes were made
> unnecessary.

Works for me.

> If there are no vocal objections to these changes, I would like to merge
> them down to trunk and proceed with potentially more inflammatory
> changes to MessageImpl, HeaderImpl, and friends.

+1

Stefano