james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: mime4j 0.6 preview packages
Date Sun, 15 Feb 2009 15:55:53 GMT
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

Mime
View raw message