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 16:06:29 GMT
Stefano Bagnara wrote:
> Oleg Kalnichevski ha scritto:
>> 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.
> 
> -Plocal has been introduced as a *compromise* by me 2 years ago, after
> working weeks (if not months) trying to satisfy really strict security
> requirements from other PMC members. They was rejecting the use of maven
> to make releases if this meant to use remote repositories because of
> security concerns.
> 
> Even if I understand and share the security issues and the
> reproducibility issues with m2, I always thought that the whole issue
> was a big waste of time for me and for the JAMES project. THE solution
> for maven and this issue is to setup our own repository with a
> repository manager. Unfortunately it seems there is no will to setup
> this kind of 3rd party repository inside the ASF.
> 
> The whole thing had already found inconsistency when we decided that we
> was not entitled shipping poms for jars that we ship in the stage folder
> (expecially wrt javamail stuff).
> 
> That said, here is my +1 to remove the -Plocal suggestion in BUILDING.txt.
> 
> Stefano

I tweaked BUILDING.txt a little. Please review and make corrections you 
deem necessary.

Oleg

Mime
View raw message