Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

On Fri, 2010-01-08 at 11:19 +0100, Stefano Bagnara wrote:
> 2010/1/8 Oleg Kalnichevski <ol...@apache.org>:
> > I spent more time working with your code. The refactoring of
> > MimeTokenStream makes good sense. However, the unfortunate choice of
> > package and class names sent a completely wrong message.
> 
> Happy to hear this! So, maybe I'll take the time to apply some package
> name changes to let the correct message pass throught.
> 
> > It led me to
> > believe one package was meant to represent public API with impl package
> > being implementation of that API. If the following changes can be made
> > to package / class naming I can happily vote +1 to merging down the
> > entire branch. Smaller issues such as #unread() method modality can be
> > dealt with on the trunk.
> >

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

(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.

(3) Tons of javadocs need to be reviewed / updated. I am willing to
help.

Oleg

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

Stefano Bagnara wrote:
> 2010/1/18 Norman Maurer <no...@googlemail.com>:
>> Hi Stefano,
>>
>> IMHO every "blocking" problems seems to be resolved by now. I would
>> just merge it to trunk.. If Robert really things that it was an bad
>> idea later, we can discuss how to solve it then in trunk...
> 

...

  started removing stage and upgrading to the "current"
> build practices.
> 

Finally! Big +1

Oleg


> Stefano
> 

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/18 Norman Maurer <no...@googlemail.com>:
> Hi Stefano,
>
> IMHO every "blocking" problems seems to be resolved by now. I would
> just merge it to trunk.. If Robert really things that it was an bad
> idea later, we can discuss how to solve it then in trunk...

It's a couple of weeks I don't touch the code so I just merged the
branch to trunk, moved back any resolved/in progress issue from 0.8 to
0.7 and just started removing stage and upgrading to the "current"
build practices.

Stefano

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

[Norman Maurer <no...@googlemail.com>]

Hi Stefano,

IMHO every "blocking" problems seems to be resolved by now. I would
just merge it to trunk.. If Robert really things that it was an bad
idea later, we can discuss how to solve it then in trunk...

Bye,
Norman

2010/1/14 Stefano Bagnara <ap...@bago.org>:
> 2010/1/13 Markus Wiederkehr <ma...@gmail.com>:
>> 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.
>
> I agree. So let's wait to hear Robert, with the hope he changed his mind.
>
> Stefano
>

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/14 Norman Maurer <no...@googlemail.com>:
> Hi Markus,
>
> svn rm and svn mv are not a good way for doing this.. This will affect
> history ...

if we do a merge then we'll keep trunk history (during the branch) but
every revision done in the branch will be lost. If we do the rm+mv
then we'll keep branch revisions but loose any change done in trunk
during the branch. Given that we had no changes in trunk during the
branch it seems that rm+mv is the best choice.

Stefano

> Bye,
> Norman
>
> 2010/1/13 Markus Wiederkehr <ma...@gmail.com>:
>> On Wed, Jan 13, 2010 at 6:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>> 2010/1/8 Oleg Kalnichevski <ol...@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
>>
>

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

[Norman Maurer <no...@googlemail.com>]

Hi Markus,

svn rm and svn mv are not a good way for doing this.. This will affect
history ...

Bye,
Norman

2010/1/13 Markus Wiederkehr <ma...@gmail.com>:
> On Wed, Jan 13, 2010 at 6:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> 2010/1/8 Oleg Kalnichevski <ol...@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
>

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/13 Markus Wiederkehr <ma...@gmail.com>:
> 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.

I agree. So let's wait to hear Robert, with the hope he changed his mind.

Stefano

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

[Markus Wiederkehr <ma...@gmail.com>]

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

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/8 Oleg Kalnichevski <ol...@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.

Stefano

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/8 Oleg Kalnichevski <ol...@apache.org>:
> Stefano Bagnara wrote:
>> 2010/1/8 Oleg Kalnichevski <ol...@apache.org>:
>>> I just do not want to end up in a situation when 'stream' package simply
>>> cannot be used without 'parser' stuff thus rendering the whole idea of
>>> separating the two pointless.
>>
>> It is a detail, but I don't agree with this reasoning. packages help
>> defining the project structure and the component dependencies.
>> Whenever it is possible to put evidence on the dependencies of a group
>> of classes and their concerns it is a good practice to do that. With
>> your reasoning abstract packages (interfaces and abstract classes
>> only) wouldn't exists because they cannot be used alone!
>>
>
> There is nothing that makes 'stream' package abstract. BasicMimeTokenStream
> is a concrete class and therefore I think 'stream' package should have a
> concrete MutableBodyDescriptor implementation

It was just an example, to prove that the rule to make packages is not
"if they are useful alone" but there are other motivations (of course
in my opinion). BTW I don't care/need to convince you on this. I'm
fine with moving the class by now.

> At the same time I think ContentHandler and AbstractContentHandler should go
> to 'parser' package. They are not used anywhere in 'stream' and even
> conceptually do not belong there. They belong to 'parser'.

I'm fine with this change. It's just a matter of defining the approach
and trying to be consistent. IMO this was only a first step, and we'll
need more changes once we decide how we want to deal with dom
operations and field parsing (see the first message of this thread).

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

Stefano Bagnara wrote:
> 2010/1/8 Oleg Kalnichevski <ol...@apache.org>:
>> Stefano Bagnara wrote:
>>> 2010/1/8 Oleg Kalnichevski <ol...@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
>>> DefaultBodyDescriptor would reintroduce the field parsing dependency
>>> to the stream package.
>> Unless I am missing something, I can't see any mime4j dependencies other
>> than on 'util' and 'stream'
>> ---
>> import org.apache.james.mime4j.stream.BodyDescriptor;
>> import org.apache.james.mime4j.stream.MutableBodyDescriptor;
>> import org.apache.james.mime4j.stream.RawField;
>> import org.apache.james.mime4j.util.MimeUtil;
>> ---
>> I do not see why this class cannot be moved to 'stream' without introducing
>> cyclic dependencies.
> 
> I'll check it. In my mind it was dependin on field parsing, but I
> remember I moved there the "getHeaderParams" method, so it does its
> own parsing. In my mind the right solution was to move also that
> method to the field parsing packages and so also this class would
> depend on the field parsing, btw maybe you are right and we can move
> the default body descriptor there, by now.
> 
>> So, unless we say that we don't care about
>>> separation between stream parser and field parsing, there is no way to
>>> use stream alone.
>> I just do not want to end up in a situation when 'stream' package simply
>> cannot be used without 'parser' stuff thus rendering the whole idea of
>> separating the two pointless.
> 
> It is a detail, but I don't agree with this reasoning. packages help
> defining the project structure and the component dependencies.
> Whenever it is possible to put evidence on the dependencies of a group
> of classes and their concerns it is a good practice to do that. With
> your reasoning abstract packages (interfaces and abstract classes
> only) wouldn't exists because they cannot be used alone!
> 

There is nothing that makes 'stream' package abstract. 
BasicMimeTokenStream is a concrete class and therefore I think 'stream' 
package should have a concrete MutableBodyDescriptor implementation

At the same time I think ContentHandler and AbstractContentHandler 
should go to 'parser' package. They are not used anywhere in 'stream' 
and even conceptually do not belong there. They belong to 'parser'.

Oleg

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/8 Oleg Kalnichevski <ol...@apache.org>:
> Stefano Bagnara wrote:
>>
>> 2010/1/8 Oleg Kalnichevski <ol...@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
>>
>> DefaultBodyDescriptor would reintroduce the field parsing dependency
>> to the stream package.
>
> Unless I am missing something, I can't see any mime4j dependencies other
> than on 'util' and 'stream'
> ---
> import org.apache.james.mime4j.stream.BodyDescriptor;
> import org.apache.james.mime4j.stream.MutableBodyDescriptor;
> import org.apache.james.mime4j.stream.RawField;
> import org.apache.james.mime4j.util.MimeUtil;
> ---
> I do not see why this class cannot be moved to 'stream' without introducing
> cyclic dependencies.

I'll check it. In my mind it was dependin on field parsing, but I
remember I moved there the "getHeaderParams" method, so it does its
own parsing. In my mind the right solution was to move also that
method to the field parsing packages and so also this class would
depend on the field parsing, btw maybe you are right and we can move
the default body descriptor there, by now.

> So, unless we say that we don't care about
>>
>> separation between stream parser and field parsing, there is no way to
>> use stream alone.
>
> I just do not want to end up in a situation when 'stream' package simply
> cannot be used without 'parser' stuff thus rendering the whole idea of
> separating the two pointless.

It is a detail, but I don't agree with this reasoning. packages help
defining the project structure and the component dependencies.
Whenever it is possible to put evidence on the dependencies of a group
of classes and their concerns it is a good practice to do that. With
your reasoning abstract packages (interfaces and abstract classes
only) wouldn't exists because they cannot be used alone!

BTW let's move the default body descriptor there, by now, and we'll
see where the future bring us.

>> Thank you for reviewing, and let me know if you prefer the older
>> packaging or the newer one (cycleclean vs
>> cycleclean-pre-packagerenames)
>> Stefano
>
> I am fine with the new package names, hence my +1 to merge.

OK,
Stefano

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

Stefano Bagnara wrote:
> 2010/1/8 Oleg Kalnichevski <ol...@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
> 
> DefaultBodyDescriptor would reintroduce the field parsing dependency
> to the stream package. 

Unless I am missing something, I can't see any mime4j dependencies other 
than on 'util' and 'stream'
---
import org.apache.james.mime4j.stream.BodyDescriptor;
import org.apache.james.mime4j.stream.MutableBodyDescriptor;
import org.apache.james.mime4j.stream.RawField;
import org.apache.james.mime4j.util.MimeUtil;
---
I do not see why this class cannot be moved to 'stream' without 
introducing cyclic dependencies.


So, unless we say that we don't care about
> separation between stream parser and field parsing, there is no way to
> use stream alone. 

I just do not want to end up in a situation when 'stream' package simply 
cannot be used without 'parser' stuff thus rendering the whole idea of 
separating the two pointless.

> 
> Thank you for reviewing, and let me know if you prefer the older
> packaging or the newer one (cycleclean vs
> cycleclean-pre-packagerenames)
> Stefano
> 

I am fine with the new package names, hence my +1 to merge.

Oleg

Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions

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

2010/1/8 Oleg Kalnichevski <ol...@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

DefaultBodyDescriptor would reintroduce the field parsing dependency
to the stream package. So, unless we say that we don't care about
separation between stream parser and field parsing, there is no way to
use stream alone. Currently the BodyDescriptor interface is the
"service" that let the "stream" parser to describe the body without
having any knowledge about what fields describe them and how they are
parsed. Not sure this is the best solution we can find, but this is
how it currently works and how it currently allow us to keep
separation between the 2 packages.

About Maximal and Default BodyDescriptors I didn't studied the
details, but currently my opinion is that we don't need 2 of them.
MaximalBodyDescriptor is already lazy parsing additional fields, so
even if you just need the defaultbodydescriptor stuff performances
would not be hit by using the Maximal.

> (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'm on windows too :-( ... I remember I worked around this issue in
older mime4j versions, too... I'll have a look at it.

> (3) Tons of javadocs need to be reviewed / updated. I am willing to
> help.

Whenever I move some stuff around the javadocs are not always
correctly updated, so I just wanted to collect more thoughts about the
merging and then deal with this details.

Thank you for reviewing, and let me know if you prefer the older
packaging or the newer one (cycleclean vs
cycleclean-pre-packagerenames)
Stefano