mime4j 0.6 preview packages

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

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

Packages:
http://people.apache.org/~olegk/mime4j-0.6-preview/

Web site:
http://people.apache.org/~olegk/mime4j-0.6-preview/site/

If there are no issues reported within a couple of days 
I will go ahead with building the official release packages and calling
a release vote.

Oleg

Re: mime4j 0.6 preview packages

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Feb 8, 2009 at 1:35 PM, Oleg Kalnichevski <ol...@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
>
> Packages:
> http://people.apache.org/~olegk/mime4j-0.6-preview/
>
> Web site:
> http://people.apache.org/~olegk/mime4j-0.6-preview/site/
>
> If there are no issues reported within a couple of days
> I will go ahead with building the official release packages and calling
> a release vote.

looks good :-)

- robert

Re: m2 and -Plocal (was: mime4j 0.6 preview packages)

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Feb 15, 2009 at 8:41 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>> On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <ap...@bago.org> wrote:
>> <snip/>
>>
>>>>> 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.
>>
>> For me the foremost reason to not rely on a remote maven repos is that
>> I firmly believe that any ASF project should be self-hosting.
>> (I'm repeating myself here of course, but I'd like to say it again as
>> the maven question has been brought up again.)
>> Self-hosting has its limits, of course we won't keep copies of ant or
>> the JDK around. But all the funny (to use a nice f-word) little maven
>> dependencies and plug-ins can really make your day, especially when
>> not accessible, either because servers are unreachable or working
>> offline.

i can appreciate this reasoning

i think that maintaining an offline build capability would be easier
than the current compromise

<snip>

>> For example: I'm connected to the net right now. I run 'mvn
>> dependency:tree', on a James server trunk checkout and I'm getting
>> errors. Mmhhh. Maybe this mvn build is not maintained, but the general
>> experience is: If maven works, you're fine. But if you get dependency
>> errors, you are really in trouble.

the maven build is currently broken but i'm working on fixing it

> I feel the same with any build tool I don't know. Whenever I have to
> build a python or perl project if it works I'm fine, but if I get any
> error I'm really in trouble. It's just a matter of knowledge of the
> tool. The choice of the build tool is just as important as the choice of
> the language or the choice of a dependency.

the continuous integration needs sorting out (too much to do, too
little time), and IMHO should be running both maven and ant builds

>> Purging a local m2 repo cannot be recommended. So prestine builds are
>> not really happening, because of the local m2.
>
> You can specify a custom local repository when you run m2.

i now clean the repo for my build user but not when i develop

>> What if somebody wants to build one of our mvn dependent products in 5
>> or 10 years? Should that work? I firmly doubt it will!
>
> IMO to release is much more important than to be able to reproduce a
> release in 10 years. So first we should be able to release with no PITA,
> then when there will be spare cycle we'll find time to create a virtual
> machine with the right os, the right libraries, the right JVM, the right
> DATE/TIME of the virtual machine, the right build tool, and all the
> dependencies.

getting a working offline build isn't that much of a hassle for a
release. what's much more annoying is the active excluding of
repositories for security reasons since this slows down development
for IMHO little gain.

>> Maybe the solution is to establish a repo for our James product
>> dependencies here in our own project. But that will likely create
>> distribution issues.
>>
>> I don't want to be a PITA, you can change the build to not depend on
>> -Plocal. I backup my local m2 anyway.
>
> IMHO ASF should have an ASF managed m2 repository (the maven central is
> managed by apache people, but not with their apache hats). Or even
> better, each PMC should have its own repository (disk space is cheap,
> cheaper than discussions to achieve compromises).

the pre-requisite to this would be solving the known potential
licensing and security issues. if these were solved then there would
be little to be gained by hosting a general repository at apache.

- robert

Re: m2 and -Plocal (was: mime4j 0.6 preview packages)

[Bernd Fondermann <be...@googlemail.com>]

On Sun, Feb 15, 2009 at 21:41, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>> On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <ap...@bago.org> wrote:
>> <snip/>
>>
>>>>> 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.
>>
>> For me the foremost reason to not rely on a remote maven repos is that
>> I firmly believe that any ASF project should be self-hosting.
>> (I'm repeating myself here of course, but I'd like to say it again as
>> the maven question has been brought up again.)
>> Self-hosting has its limits, of course we won't keep copies of ant or
>> the JDK around. But all the funny (to use a nice f-word) little maven
>> dependencies and plug-ins can really make your day, especially when
>> not accessible, either because servers are unreachable or working
>> offline.
>
> Have you ever tried a repository manager? (e.g: Nexus, or Archiva if you
> want to stay Apache).

I know them. There are simply no additional benefits for me in them.

>> For example: I'm connected to the net right now. I run 'mvn
>> dependency:tree', on a James server trunk checkout and I'm getting
>> errors. Mmhhh. Maybe this mvn build is not maintained, but the general
>> experience is: If maven works, you're fine. But if you get dependency
>> errors, you are really in trouble.
>
> I feel the same with any build tool I don't know. Whenever I have to
> build a python or perl project if it works I'm fine, but if I get any
> error I'm really in trouble. It's just a matter of knowledge of the
> tool. The choice of the build tool is just as important as the choice of
> the language or the choice of a dependency.

I know maven well enough. I use it nearly every day. That's not the
problem here.

>> Purging a local m2 repo cannot be recommended. So prestine builds are
>> not really happening, because of the local m2.
>
> You can specify a custom local repository when you run m2.

I know. But who does that before building? Robert. But no other sane person.

>> What if somebody wants to build one of our mvn dependent products in 5
>> or 10 years? Should that work? I firmly doubt it will!
>
> IMO to release is much more important than to be able to reproduce a
> release in 10 years.

We primarily ship code. Do you say we should stop that, because it's
not important if that works (now or in 1 or 5 or 10 years)? To build a
src dist with mvn you need resolve much to much dependencies (IMHO).

> So first we should be able to release with no PITA,

at least this works with maven ;-)

> then when there will be spare cycle we'll find time to create a virtual
> machine with the right os, the right libraries, the right JVM, the right
> DATE/TIME of the virtual machine, the right build tool, and all the
> dependencies.
>
>> Maybe the solution is to establish a repo for our James product
>> dependencies here in our own project. But that will likely create
>> distribution issues.
>>
>> I don't want to be a PITA, you can change the build to not depend on
>> -Plocal. I backup my local m2 anyway.
>
> IMHO ASF should have an ASF managed m2 repository (the maven central is
> managed by apache people, but not with their apache hats). Or even
> better, each PMC should have its own repository (disk space is cheap,
> cheaper than discussions to achieve compromises).
>
> Stefano
>

Bernd

m2 and -Plocal (was: mime4j 0.6 preview packages)

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

Bernd Fondermann ha scritto:
> On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <ap...@bago.org> wrote:
> <snip/>
> 
>>>> 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.
> 
> For me the foremost reason to not rely on a remote maven repos is that
> I firmly believe that any ASF project should be self-hosting.
> (I'm repeating myself here of course, but I'd like to say it again as
> the maven question has been brought up again.)
> Self-hosting has its limits, of course we won't keep copies of ant or
> the JDK around. But all the funny (to use a nice f-word) little maven
> dependencies and plug-ins can really make your day, especially when
> not accessible, either because servers are unreachable or working
> offline.

Have you ever tried a repository manager? (e.g: Nexus, or Archiva if you
want to stay Apache).

> For example: I'm connected to the net right now. I run 'mvn
> dependency:tree', on a James server trunk checkout and I'm getting
> errors. Mmhhh. Maybe this mvn build is not maintained, but the general
> experience is: If maven works, you're fine. But if you get dependency
> errors, you are really in trouble.

I feel the same with any build tool I don't know. Whenever I have to
build a python or perl project if it works I'm fine, but if I get any
error I'm really in trouble. It's just a matter of knowledge of the
tool. The choice of the build tool is just as important as the choice of
the language or the choice of a dependency.

> Purging a local m2 repo cannot be recommended. So prestine builds are
> not really happening, because of the local m2.

You can specify a custom local repository when you run m2.

> What if somebody wants to build one of our mvn dependent products in 5
> or 10 years? Should that work? I firmly doubt it will!

IMO to release is much more important than to be able to reproduce a
release in 10 years. So first we should be able to release with no PITA,
then when there will be spare cycle we'll find time to create a virtual
machine with the right os, the right libraries, the right JVM, the right
DATE/TIME of the virtual machine, the right build tool, and all the
dependencies.

> Maybe the solution is to establish a repo for our James product
> dependencies here in our own project. But that will likely create
> distribution issues.
> 
> I don't want to be a PITA, you can change the build to not depend on
> -Plocal. I backup my local m2 anyway.

IMHO ASF should have an ASF managed m2 repository (the maven central is
managed by apache people, but not with their apache hats). Or even
better, each PMC should have its own repository (disk space is cheap,
cheaper than discussions to achieve compromises).

Stefano

Re: mime4j 0.6 preview packages

[Bernd Fondermann <be...@googlemail.com>]

On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <ap...@bago.org> wrote:
<snip/>

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

For me the foremost reason to not rely on a remote maven repos is that
I firmly believe that any ASF project should be self-hosting.
(I'm repeating myself here of course, but I'd like to say it again as
the maven question has been brought up again.)
Self-hosting has its limits, of course we won't keep copies of ant or
the JDK around. But all the funny (to use a nice f-word) little maven
dependencies and plug-ins can really make your day, especially when
not accessible, either because servers are unreachable or working
offline.

For example: I'm connected to the net right now. I run 'mvn
dependency:tree', on a James server trunk checkout and I'm getting
errors. Mmhhh. Maybe this mvn build is not maintained, but the general
experience is: If maven works, you're fine. But if you get dependency
errors, you are really in trouble.
Purging a local m2 repo cannot be recommended. So prestine builds are
not really happening, because of the local m2.

What if somebody wants to build one of our mvn dependent products in 5
or 10 years? Should that work? I firmly doubt it will!

Maybe the solution is to establish a repo for our James product
dependencies here in our own project. But that will likely create
distribution issues.

I don't want to be a PITA, you can change the build to not depend on
-Plocal. I backup my local m2 anyway.

  Bernd

Re: mime4j 0.6 preview packages

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

Stefano Bagnara wrote:
> Oleg Kalnichevski ha scritto:
>> Markus Wiederkehr wrote:
>>> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@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
>>>>> <ma...@gmail.com> wrote:
>>>>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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

Re: mime4j 0.6 preview packages

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Feb 15, 2009 at 4:43 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sun, Feb 15, 2009 at 3:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Oleg Kalnichevski ha scritto:
>>> Markus Wiederkehr wrote:
>>>> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@apache.org>
>
> <snip>
>
>>>> 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.
>
> i never really understood the detail behind these concerns
>
> maven uses lots of dependencies, many of which it downloads. so, the
> direct way to infect a release would be by compromising the build tool
> itself (maven). compromising a released jar through a malware compile
> time dependency sounds like something which would require a lot of
> skill.
>
> if maven isn't secure enough then it should be used at all
                                                            ^^^^^^^^
                                                            shouldn't be

- robert

Re: mime4j 0.6 preview packages

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Feb 15, 2009 at 3:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Oleg Kalnichevski ha scritto:
>> Markus Wiederkehr wrote:
>>> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@apache.org>

<snip>

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

i never really understood the detail behind these concerns

maven uses lots of dependencies, many of which it downloads. so, the
direct way to infect a release would be by compromising the build tool
itself (maven). compromising a released jar through a malware compile
time dependency sounds like something which would require a lot of
skill.

if maven isn't secure enough then it should be used at all

> 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 conclusion i reached is that this wouldn't be good enough anyway.
what would be required is a hardened version of maven.

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

licensing issues make it hard to use stage effective

- robert

Re: mime4j 0.6 preview packages

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

Oleg Kalnichevski ha scritto:
> Markus Wiederkehr wrote:
>> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@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
>>>> <ma...@gmail.com> wrote:
>>>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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

Re: mime4j 0.6 preview packages

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

Markus Wiederkehr wrote:
> On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@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
>>> <ma...@gmail.com> wrote:
>>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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

Re: mime4j 0.6 preview packages

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

On Mon, Feb 9, 2009 at 7:53 PM, Oleg Kalnichevski <ol...@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
>> <ma...@gmail.com> wrote:
>>>
>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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?

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

Markus

Re: mime4j 0.6 preview packages

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Feb 9, 2009 at 6:53 PM, Oleg Kalnichevski <ol...@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
>> <ma...@gmail.com> wrote:
>>>
>>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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.

ok

i've patched RELEASE_NOTES.txt. hopefully, i've addressed all the
improvements suggested.

AFACT everything's good

- robert

Re: mime4j 0.6 preview packages

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

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
> <ma...@gmail.com> wrote:
>> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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.

Oleg

Re: mime4j 0.6 preview packages

[Robert Burrell Donkin <ro...@gmail.com>]

(i hope to do a proper review of the releases tomorrow)

On Sun, Feb 8, 2009 at 3:25 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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

Re: mime4j 0.6 preview packages

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

On Sun, Feb 8, 2009 at 2:35 PM, Oleg Kalnichevski <ol...@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; number 2 should have been resolved
sufficiently in the course of MIME4J-34..

> Packages:
> http://people.apache.org/~olegk/mime4j-0.6-preview/
>
> Web site:
> http://people.apache.org/~olegk/mime4j-0.6-preview/site/

Looks good to me.

Markus

>
> If there are no issues reported within a couple of days
> I will go ahead with building the official release packages and calling
> a release vote.
>
> Oleg
>