james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: mime4j 0.6 preview packages
Date Sun, 15 Feb 2009 15:09:43 GMT
Markus Wiederkehr wrote:
> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
>> Robert Burrell Donkin wrote:
>>> (i hope to do a proper review of the releases tomorrow)
>>>
>>> On Sun, Feb 8, 2009 at 3:25 PM, Markus Wiederkehr
>>> <markus.wiederkehr@gmail.com> wrote:
>>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <olegk@apache.org>
>>>> wrote:
>>>>> Folks
>>>>>
>>>>> Please do take a few minutes to review the release notes, packages and
>>>>> the updated web site for the upcoming 0.6 release.
>>>>>
>>>>> Release notes:
>>>>> http://people.apache.org/~olegk/mime4j-0.6-preview/RELEASE_NOTES.txt
>>>> I wonder if we should include any or all of the older notes from 0.4 and
>>>> 0.5:
>>>>
>>>>  * Mime4j API is still considered unstable and is likely to change in
>>>> future releases
>>>>  * DOM support has known limitations and some roundtrip issues remain
>>>> to be resolved
>>>>  * Some low level functions are available only in the pull parser
>>>> (recommended for
>>>>  advanced users)
>>>>
>>>> I would opt for numbers 1 and 3;
>>> +1
>>>
>>>> number 2 should have been resolved
>>>> sufficiently in the course of MIME4J-34..
>>> probably worth saying something about 2, maybe
>>>
>>> "The DOM API has been now been comprehensively refactored and the
>>> known limitations addressed. Please report any remaining issues to
>>> https://issues.apache.org/jira/browse/MIME4J."
>>>
>>> we should probably add something about the known limitations of some
>>> of the field parsing code, maybe something like
>>>
>>> "0.6 contains a mixture of approaches to the parsing of advanced MIME
>>> field types. Limitations are known with these approaches with some
>>> relatively uncommon use cases. A consistent and comprehensive rewrite
>>> is planned for 0.7 which should consolidate and address these."
>>>
>>> - robert
>>
>> Markus, Robert
>>
>> Sounds very reasonable. There is no need for a complex protocol. Just go
>> ahead and apply changes that you deem necessary.
> 
> I wonder if the information in BUILDING.txt is still up to date?
>

It can certainly be improved. I'll look into it.


> Is maven version 2.0.6 still sufficient?
> And for me "mvn package" always did the job; no -U, no -Plocal..
> 

Neither option is required. I guess -Plocal can come handy when building 
packages while off-line.

Oleg

> Markus


Mime
View raw message