You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2011/07/15 14:32:07 UTC
As far as I am concerned 0.7 is ready
Folks,
As far as I am concerned 0.7 is ready. At this point I do not think
there is really that much more I could contribute.
I am stepping aside and letting someone else take over from this point
on.
Cheers
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
Ok let us target it for 0.8 then. I will get the release process
rolling later this evening...
Bye,
Norman
2011/7/18 Stefano Bagnara <ap...@bago.org>:
> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
>> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>>> > Hi there,
>>> >
>>> > just to be more clear. I'm not very strong with it, so if others
>>> > prefer we can just release it like it is...
>>>
>>> I leave this to you and Oleg. Either way it is not an elegant solution
>>> and we'll need to fix that part of the api (configuration + advanced
>>> features) in future releases (IMO).
>>>
>>> Stefano
>>>
>>
>> Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>> was not of my making. I had nothing to do with it and have nothing to
>> contribute there.
>
> What we have now is the result of what I did in a first place and how
> you changed it to make it pass your review.
>
> You wanted to remove the abstract classes in favor of interfaces for
> parser/builders and wanted to remove that methods I added (e.g:
> setDecodeMonitor was a method of the public api abstract class), so
> you can't say "I had nothing to do with it", now ;-)
>
> As I said I'm fine with a 0.7 release from the current trunk, but this
> doesn't mean that dom is complete and stable: as we call it 0.x I
> don't see issues with this plan and there is no need to delay the
> release more.
>
> Stefano
>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@apache.org>.
Hi,
I upgraded imap and mailbox yesterday on my mac and everything still work.
So I think we are ready,
Norman
Am 19.07.2011 11:04, schrieb Norman Maurer:
> I will update mime4j for this projects later today to see if
> everything works out..
>
> Thanks,
> Norman
>
>
> 2011/7/19 Stefano Bagnara<ap...@bago.org>:
>> 2011/7/19 Oleg Kalnichevski<ol...@apache.org>:
>>> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>>>> 2011/7/18 Oleg Kalnichevski<ol...@apache.org>:
>>>>> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>>>>> 2011/7/18 Norman Maurer<no...@googlemail.com>:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> just to be more clear. I'm not very strong with it, so if others
>>>>>>> prefer we can just release it like it is...
>>>>>> I leave this to you and Oleg. Either way it is not an elegant solution
>>>>>> and we'll need to fix that part of the api (configuration + advanced
>>>>>> features) in future releases (IMO).
>>>>>>
>>>>>> Stefano
>>>>>>
>>>>> Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>>>>> was not of my making. I had nothing to do with it and have nothing to
>>>>> contribute there.
>>>> What we have now is the result of what I did in a first place and how
>>>> you changed it to make it pass your review.
>>>>
>>>> You wanted to remove the abstract classes in favor of interfaces for
>>>> parser/builders and wanted to remove that methods I added (e.g:
>>>> setDecodeMonitor was a method of the public api abstract class), so
>>>> you can't say "I had nothing to do with it", now ;-)
>>>>
>>> Stefano
>>>
>>> MessageServiceFactory is an abstract class, not an interface. So, I have
>>> no idea what you are talking about. Feel free to add whatever methods to
>>> that class you please.
>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>>
>> You see we had an abstract MessageBuilder (now it is an interface) and
>> that abstract class exposed setDecodeMonitor.
>>
>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>>
>> You see this revision is when YOU changed from abstract class to
>> interface and removed the setDecodeMonitor. I'm talking of this very
>> method and that very class/interface.
>>
>> I simply found that after your refactorings I was not able anymore to
>> use the decodemonitor (while previously I used them and used in a
>> typed manner), so I asked if this was intended and how you wanted me
>> to deal with it (I know how I would like it to work, but we already
>> saw that my solution is not acceptable to you, so I simply asked you
>> what was acceptable and it sounded weird when you replied that you had
>> nothing to do with this stuff).
>>
>> I now added the DecodeMonitor as a setAttribute for the factory as for
>> your request but it was not in the factory previously.
>>
>> If adding typed methods to the MessageServiceFactory (for things we
>> now have in setAttribute) is acceptable to you then I'll vet them and
>> add methods I think are to there stay for 0.8. It is an abstract class
>> so we can add this new methods in future with no backward
>> compatibility issues.
>>
>> Hope this explains "what I'm talking about" :-)
>>
>> I succesfully upgraded jdkim and 2 local projects to the current
>> trunk. I had no time to try to upgrade imap/mailbox to see if anything
>> else is needed, but I don't plan to have time soon, so unless Norman
>> wants to look at it, IMO we can proceed to the release.
>>
>> Stefano
>>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
I will update mime4j for this projects later today to see if
everything works out..
Thanks,
Norman
2011/7/19 Stefano Bagnara <ap...@bago.org>:
> 2011/7/19 Oleg Kalnichevski <ol...@apache.org>:
>> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>>> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
>>> > On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>> >> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>>> >> > Hi there,
>>> >> >
>>> >> > just to be more clear. I'm not very strong with it, so if others
>>> >> > prefer we can just release it like it is...
>>> >>
>>> >> I leave this to you and Oleg. Either way it is not an elegant solution
>>> >> and we'll need to fix that part of the api (configuration + advanced
>>> >> features) in future releases (IMO).
>>> >>
>>> >> Stefano
>>> >>
>>> >
>>> > Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>>> > was not of my making. I had nothing to do with it and have nothing to
>>> > contribute there.
>>>
>>> What we have now is the result of what I did in a first place and how
>>> you changed it to make it pass your review.
>>>
>>> You wanted to remove the abstract classes in favor of interfaces for
>>> parser/builders and wanted to remove that methods I added (e.g:
>>> setDecodeMonitor was a method of the public api abstract class), so
>>> you can't say "I had nothing to do with it", now ;-)
>>>
>>
>> Stefano
>>
>> MessageServiceFactory is an abstract class, not an interface. So, I have
>> no idea what you are talking about. Feel free to add whatever methods to
>> that class you please.
>
> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>
> You see we had an abstract MessageBuilder (now it is an interface) and
> that abstract class exposed setDecodeMonitor.
>
> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>
> You see this revision is when YOU changed from abstract class to
> interface and removed the setDecodeMonitor. I'm talking of this very
> method and that very class/interface.
>
> I simply found that after your refactorings I was not able anymore to
> use the decodemonitor (while previously I used them and used in a
> typed manner), so I asked if this was intended and how you wanted me
> to deal with it (I know how I would like it to work, but we already
> saw that my solution is not acceptable to you, so I simply asked you
> what was acceptable and it sounded weird when you replied that you had
> nothing to do with this stuff).
>
> I now added the DecodeMonitor as a setAttribute for the factory as for
> your request but it was not in the factory previously.
>
> If adding typed methods to the MessageServiceFactory (for things we
> now have in setAttribute) is acceptable to you then I'll vet them and
> add methods I think are to there stay for 0.8. It is an abstract class
> so we can add this new methods in future with no backward
> compatibility issues.
>
> Hope this explains "what I'm talking about" :-)
>
> I succesfully upgraded jdkim and 2 local projects to the current
> trunk. I had no time to try to upgrade imap/mailbox to see if anything
> else is needed, but I don't plan to have time soon, so unless Norman
> wants to look at it, IMO we can proceed to the release.
>
> Stefano
>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@apache.org>.
Am 19.07.2011 11:29, schrieb Stefano Bagnara:
> 2011/7/19 Oleg Kalnichevski<ol...@apache.org>:
>> On Tue, 2011-07-19 at 11:00 +0200, Stefano Bagnara wrote:
>>> 2011/7/19 Oleg Kalnichevski<ol...@apache.org>:
>>>> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>>>>> 2011/7/18 Oleg Kalnichevski<ol...@apache.org>:
>>>>>> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>>>>>> 2011/7/18 Norman Maurer<no...@googlemail.com>:
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> just to be more clear. I'm not very strong with it, so if others
>>>>>>>> prefer we can just release it like it is...
>>>>>>> I leave this to you and Oleg. Either way it is not an elegant solution
>>>>>>> and we'll need to fix that part of the api (configuration + advanced
>>>>>>> features) in future releases (IMO).
>>>>>>>
>>>>>>> Stefano
>>>>>>>
>>>>>> Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>>>>>> was not of my making. I had nothing to do with it and have nothing to
>>>>>> contribute there.
>>>>> What we have now is the result of what I did in a first place and how
>>>>> you changed it to make it pass your review.
>>>>>
>>>>> You wanted to remove the abstract classes in favor of interfaces for
>>>>> parser/builders and wanted to remove that methods I added (e.g:
>>>>> setDecodeMonitor was a method of the public api abstract class), so
>>>>> you can't say "I had nothing to do with it", now ;-)
>>>>>
>>>> Stefano
>>>>
>>>> MessageServiceFactory is an abstract class, not an interface. So, I have
>>>> no idea what you are talking about. Feel free to add whatever methods to
>>>> that class you please.
>>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>>>
>>> You see we had an abstract MessageBuilder (now it is an interface) and
>>> that abstract class exposed setDecodeMonitor.
>>>
>>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>>>
>>> You see this revision is when YOU changed from abstract class to
>>> interface and removed the setDecodeMonitor. I'm talking of this very
>>> method and that very class/interface.
>>>
>>> I simply found that after your refactorings I was not able anymore to
>>> use the decodemonitor (while previously I used them and used in a
>>> typed manner), so I asked if this was intended and how you wanted me
>>> to deal with it (I know how I would like it to work, but we already
>>> saw that my solution is not acceptable to you, so I simply asked you
>>> what was acceptable and it sounded weird when you replied that you had
>>> nothing to do with this stuff).
>>>
>>> I now added the DecodeMonitor as a setAttribute for the factory as for
>>> your request but it was not in the factory previously.
>>>
>>> If adding typed methods to the MessageServiceFactory (for things we
>>> now have in setAttribute) is acceptable to you then I'll vet them and
>>> add methods I think are to there stay for 0.8. It is an abstract class
>>> so we can add this new methods in future with no backward
>>> compatibility issues.
>>>
>>> Hope this explains "what I'm talking about" :-)
>>>
>> Not really. What does this all have to do with the brokenness of
>> MessageServiceFactory / ServiceLocator stuff and the original issue
>> raised by Norman?
> I'll try again :-)
>
> We didn't talk about "brokenness". We talked about the fact that to
> use DecodeMonitor you now have to use setAttribute using a type unsafe
> method. I was explaining that I don't like too much this and he
> proposed to push the attribute names as public static fields. Hope you
> understand how this is related: if setDecodeMonitor for in the
> MessageBuilder then we wouldn't have to use
> setAttribute("DecodeMonitor", decodeMonitor) in the factory.
>
> If you don't see the relationship it's not a problem. My mind often
> does weird mental links. I record that you don't care of the
> MessageServiceFactory/ServiceLocator and I'll plan a refactory "the
> way I like it" for the next release.
>
> Thank you,
> Stefano
Said enough ;) Let us just release now ... I will start the VOTE thread
within the next few minutes..
Bye,
Norman
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/19 Oleg Kalnichevski <ol...@apache.org>:
> On Tue, 2011-07-19 at 11:00 +0200, Stefano Bagnara wrote:
>> 2011/7/19 Oleg Kalnichevski <ol...@apache.org>:
>> > On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>> >> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
>> >> > On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>> >> >> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>> >> >> > Hi there,
>> >> >> >
>> >> >> > just to be more clear. I'm not very strong with it, so if others
>> >> >> > prefer we can just release it like it is...
>> >> >>
>> >> >> I leave this to you and Oleg. Either way it is not an elegant solution
>> >> >> and we'll need to fix that part of the api (configuration + advanced
>> >> >> features) in future releases (IMO).
>> >> >>
>> >> >> Stefano
>> >> >>
>> >> >
>> >> > Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>> >> > was not of my making. I had nothing to do with it and have nothing to
>> >> > contribute there.
>> >>
>> >> What we have now is the result of what I did in a first place and how
>> >> you changed it to make it pass your review.
>> >>
>> >> You wanted to remove the abstract classes in favor of interfaces for
>> >> parser/builders and wanted to remove that methods I added (e.g:
>> >> setDecodeMonitor was a method of the public api abstract class), so
>> >> you can't say "I had nothing to do with it", now ;-)
>> >>
>> >
>> > Stefano
>> >
>> > MessageServiceFactory is an abstract class, not an interface. So, I have
>> > no idea what you are talking about. Feel free to add whatever methods to
>> > that class you please.
>>
>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>>
>> You see we had an abstract MessageBuilder (now it is an interface) and
>> that abstract class exposed setDecodeMonitor.
>>
>> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>>
>> You see this revision is when YOU changed from abstract class to
>> interface and removed the setDecodeMonitor. I'm talking of this very
>> method and that very class/interface.
>>
>> I simply found that after your refactorings I was not able anymore to
>> use the decodemonitor (while previously I used them and used in a
>> typed manner), so I asked if this was intended and how you wanted me
>> to deal with it (I know how I would like it to work, but we already
>> saw that my solution is not acceptable to you, so I simply asked you
>> what was acceptable and it sounded weird when you replied that you had
>> nothing to do with this stuff).
>>
>> I now added the DecodeMonitor as a setAttribute for the factory as for
>> your request but it was not in the factory previously.
>>
>> If adding typed methods to the MessageServiceFactory (for things we
>> now have in setAttribute) is acceptable to you then I'll vet them and
>> add methods I think are to there stay for 0.8. It is an abstract class
>> so we can add this new methods in future with no backward
>> compatibility issues.
>>
>> Hope this explains "what I'm talking about" :-)
>>
>
> Not really. What does this all have to do with the brokenness of
> MessageServiceFactory / ServiceLocator stuff and the original issue
> raised by Norman?
I'll try again :-)
We didn't talk about "brokenness". We talked about the fact that to
use DecodeMonitor you now have to use setAttribute using a type unsafe
method. I was explaining that I don't like too much this and he
proposed to push the attribute names as public static fields. Hope you
understand how this is related: if setDecodeMonitor for in the
MessageBuilder then we wouldn't have to use
setAttribute("DecodeMonitor", decodeMonitor) in the factory.
If you don't see the relationship it's not a problem. My mind often
does weird mental links. I record that you don't care of the
MessageServiceFactory/ServiceLocator and I'll plan a refactory "the
way I like it" for the next release.
Thank you,
Stefano
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2011-07-19 at 11:00 +0200, Stefano Bagnara wrote:
> 2011/7/19 Oleg Kalnichevski <ol...@apache.org>:
> > On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
> >> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
> >> > On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
> >> >> 2011/7/18 Norman Maurer <no...@googlemail.com>:
> >> >> > Hi there,
> >> >> >
> >> >> > just to be more clear. I'm not very strong with it, so if others
> >> >> > prefer we can just release it like it is...
> >> >>
> >> >> I leave this to you and Oleg. Either way it is not an elegant solution
> >> >> and we'll need to fix that part of the api (configuration + advanced
> >> >> features) in future releases (IMO).
> >> >>
> >> >> Stefano
> >> >>
> >> >
> >> > Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
> >> > was not of my making. I had nothing to do with it and have nothing to
> >> > contribute there.
> >>
> >> What we have now is the result of what I did in a first place and how
> >> you changed it to make it pass your review.
> >>
> >> You wanted to remove the abstract classes in favor of interfaces for
> >> parser/builders and wanted to remove that methods I added (e.g:
> >> setDecodeMonitor was a method of the public api abstract class), so
> >> you can't say "I had nothing to do with it", now ;-)
> >>
> >
> > Stefano
> >
> > MessageServiceFactory is an abstract class, not an interface. So, I have
> > no idea what you are talking about. Feel free to add whatever methods to
> > that class you please.
>
> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
>
> You see we had an abstract MessageBuilder (now it is an interface) and
> that abstract class exposed setDecodeMonitor.
>
> http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
>
> You see this revision is when YOU changed from abstract class to
> interface and removed the setDecodeMonitor. I'm talking of this very
> method and that very class/interface.
>
> I simply found that after your refactorings I was not able anymore to
> use the decodemonitor (while previously I used them and used in a
> typed manner), so I asked if this was intended and how you wanted me
> to deal with it (I know how I would like it to work, but we already
> saw that my solution is not acceptable to you, so I simply asked you
> what was acceptable and it sounded weird when you replied that you had
> nothing to do with this stuff).
>
> I now added the DecodeMonitor as a setAttribute for the factory as for
> your request but it was not in the factory previously.
>
> If adding typed methods to the MessageServiceFactory (for things we
> now have in setAttribute) is acceptable to you then I'll vet them and
> add methods I think are to there stay for 0.8. It is an abstract class
> so we can add this new methods in future with no backward
> compatibility issues.
>
> Hope this explains "what I'm talking about" :-)
>
Not really. What does this all have to do with the brokenness of
MessageServiceFactory / ServiceLocator stuff and the original issue
raised by Norman?
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/19 Oleg Kalnichevski <ol...@apache.org>:
> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
>> > On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>> >> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>> >> > Hi there,
>> >> >
>> >> > just to be more clear. I'm not very strong with it, so if others
>> >> > prefer we can just release it like it is...
>> >>
>> >> I leave this to you and Oleg. Either way it is not an elegant solution
>> >> and we'll need to fix that part of the api (configuration + advanced
>> >> features) in future releases (IMO).
>> >>
>> >> Stefano
>> >>
>> >
>> > Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
>> > was not of my making. I had nothing to do with it and have nothing to
>> > contribute there.
>>
>> What we have now is the result of what I did in a first place and how
>> you changed it to make it pass your review.
>>
>> You wanted to remove the abstract classes in favor of interfaces for
>> parser/builders and wanted to remove that methods I added (e.g:
>> setDecodeMonitor was a method of the public api abstract class), so
>> you can't say "I had nothing to do with it", now ;-)
>>
>
> Stefano
>
> MessageServiceFactory is an abstract class, not an interface. So, I have
> no idea what you are talking about. Feel free to add whatever methods to
> that class you please.
http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?revision=923012&view=markup&pathrev=1137643
You see we had an abstract MessageBuilder (now it is an interface) and
that abstract class exposed setDecodeMonitor.
http://svn.apache.org/viewvc/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/dom/MessageBuilder.java?r1=958717&r2=1063904&pathrev=1137643
You see this revision is when YOU changed from abstract class to
interface and removed the setDecodeMonitor. I'm talking of this very
method and that very class/interface.
I simply found that after your refactorings I was not able anymore to
use the decodemonitor (while previously I used them and used in a
typed manner), so I asked if this was intended and how you wanted me
to deal with it (I know how I would like it to work, but we already
saw that my solution is not acceptable to you, so I simply asked you
what was acceptable and it sounded weird when you replied that you had
nothing to do with this stuff).
I now added the DecodeMonitor as a setAttribute for the factory as for
your request but it was not in the factory previously.
If adding typed methods to the MessageServiceFactory (for things we
now have in setAttribute) is acceptable to you then I'll vet them and
add methods I think are to there stay for 0.8. It is an abstract class
so we can add this new methods in future with no backward
compatibility issues.
Hope this explains "what I'm talking about" :-)
I succesfully upgraded jdkim and 2 local projects to the current
trunk. I had no time to try to upgrade imap/mailbox to see if anything
else is needed, but I don't plan to have time soon, so unless Norman
wants to look at it, IMO we can proceed to the release.
Stefano
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
> > On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
> >> 2011/7/18 Norman Maurer <no...@googlemail.com>:
> >> > Hi there,
> >> >
> >> > just to be more clear. I'm not very strong with it, so if others
> >> > prefer we can just release it like it is...
> >>
> >> I leave this to you and Oleg. Either way it is not an elegant solution
> >> and we'll need to fix that part of the api (configuration + advanced
> >> features) in future releases (IMO).
> >>
> >> Stefano
> >>
> >
> > Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
> > was not of my making. I had nothing to do with it and have nothing to
> > contribute there.
>
> What we have now is the result of what I did in a first place and how
> you changed it to make it pass your review.
>
> You wanted to remove the abstract classes in favor of interfaces for
> parser/builders and wanted to remove that methods I added (e.g:
> setDecodeMonitor was a method of the public api abstract class), so
> you can't say "I had nothing to do with it", now ;-)
>
Stefano
MessageServiceFactory is an abstract class, not an interface. So, I have
no idea what you are talking about. Feel free to add whatever methods to
that class you please.
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>> > Hi there,
>> >
>> > just to be more clear. I'm not very strong with it, so if others
>> > prefer we can just release it like it is...
>>
>> I leave this to you and Oleg. Either way it is not an elegant solution
>> and we'll need to fix that part of the api (configuration + advanced
>> features) in future releases (IMO).
>>
>> Stefano
>>
>
> Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
> was not of my making. I had nothing to do with it and have nothing to
> contribute there.
What we have now is the result of what I did in a first place and how
you changed it to make it pass your review.
You wanted to remove the abstract classes in favor of interfaces for
parser/builders and wanted to remove that methods I added (e.g:
setDecodeMonitor was a method of the public api abstract class), so
you can't say "I had nothing to do with it", now ;-)
As I said I'm fine with a 0.7 release from the current trunk, but this
doesn't mean that dom is complete and stable: as we call it 0.x I
don't see issues with this plan and there is no need to delay the
release more.
Stefano
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
> 2011/7/18 Norman Maurer <no...@googlemail.com>:
> > Hi there,
> >
> > just to be more clear. I'm not very strong with it, so if others
> > prefer we can just release it like it is...
>
> I leave this to you and Oleg. Either way it is not an elegant solution
> and we'll need to fix that part of the api (configuration + advanced
> features) in future releases (IMO).
>
> Stefano
>
Sorry for being blunt but MessageServiceFactory / ServiceLocator stuff
was not of my making. I had nothing to do with it and have nothing to
contribute there.
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/18 Norman Maurer <no...@googlemail.com>:
> Hi there,
>
> just to be more clear. I'm not very strong with it, so if others
> prefer we can just release it like it is...
I leave this to you and Oleg. Either way it is not an elegant solution
and we'll need to fix that part of the api (configuration + advanced
features) in future releases (IMO).
Stefano
> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>> Maybe use some extra interface which just contains the property names.
>> It just looks ugly to not have them somewhere as a static field the
>> dev can use to set this kind of stuff. Typing the name is kind of
>> error phrone ..
>>
>> Bye,
>> Norman
>>
>>
>> 2011/7/18 Stefano Bagnara <ap...@bago.org>:
>>> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>>>>Stefano Bagnara wrote:
>>>>> My main concern is that "dom" api is a lot limited unless you use
>>>>> "setAttribute" with some magic parameter that you expect to work like
>>>>> our default implementation does. This doesn't sound good to me for an
>>>>> API.
>>>>>
>>>>> That said I'm fine with a 0.7 release from current trunk. It's not
>>>>> perfect, but a step forward from previous releases.
>>>>
>>>> i think it would sense to expose those property names as public static
>>>> fields. are you guys ok with it? If so I will commit the this and
>>>> after that start the release process...
>>>
>>> Don't know: in what class would you publish them? If they have to be
>>> part of the interface then why not to add specific/typed setters for
>>> each property? Instead if they have to be in the implementation I
>>> don't think it worth using them as (if used) it would break even more
>>> the service locator pattern.
>>>
>>> Stefano
>>>
>>
>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
Hi there,
just to be more clear. I'm not very strong with it, so if others
prefer we can just release it like it is...
Bye,
Norman
2011/7/18 Norman Maurer <no...@googlemail.com>:
> Maybe use some extra interface which just contains the property names.
> It just looks ugly to not have them somewhere as a static field the
> dev can use to set this kind of stuff. Typing the name is kind of
> error phrone ..
>
> Bye,
> Norman
>
>
> 2011/7/18 Stefano Bagnara <ap...@bago.org>:
>> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>>>Stefano Bagnara wrote:
>>>> My main concern is that "dom" api is a lot limited unless you use
>>>> "setAttribute" with some magic parameter that you expect to work like
>>>> our default implementation does. This doesn't sound good to me for an
>>>> API.
>>>>
>>>> That said I'm fine with a 0.7 release from current trunk. It's not
>>>> perfect, but a step forward from previous releases.
>>>
>>> i think it would sense to expose those property names as public static
>>> fields. are you guys ok with it? If so I will commit the this and
>>> after that start the release process...
>>
>> Don't know: in what class would you publish them? If they have to be
>> part of the interface then why not to add specific/typed setters for
>> each property? Instead if they have to be in the implementation I
>> don't think it worth using them as (if used) it would break even more
>> the service locator pattern.
>>
>> Stefano
>>
>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
Maybe use some extra interface which just contains the property names.
It just looks ugly to not have them somewhere as a static field the
dev can use to set this kind of stuff. Typing the name is kind of
error phrone ..
Bye,
Norman
2011/7/18 Stefano Bagnara <ap...@bago.org>:
> 2011/7/18 Norman Maurer <no...@googlemail.com>:
>>Stefano Bagnara wrote:
>>> My main concern is that "dom" api is a lot limited unless you use
>>> "setAttribute" with some magic parameter that you expect to work like
>>> our default implementation does. This doesn't sound good to me for an
>>> API.
>>>
>>> That said I'm fine with a 0.7 release from current trunk. It's not
>>> perfect, but a step forward from previous releases.
>>
>> i think it would sense to expose those property names as public static
>> fields. are you guys ok with it? If so I will commit the this and
>> after that start the release process...
>
> Don't know: in what class would you publish them? If they have to be
> part of the interface then why not to add specific/typed setters for
> each property? Instead if they have to be in the implementation I
> don't think it worth using them as (if used) it would break even more
> the service locator pattern.
>
> Stefano
>
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/18 Norman Maurer <no...@googlemail.com>:
>Stefano Bagnara wrote:
>> My main concern is that "dom" api is a lot limited unless you use
>> "setAttribute" with some magic parameter that you expect to work like
>> our default implementation does. This doesn't sound good to me for an
>> API.
>>
>> That said I'm fine with a 0.7 release from current trunk. It's not
>> perfect, but a step forward from previous releases.
>
> i think it would sense to expose those property names as public static
> fields. are you guys ok with it? If so I will commit the this and
> after that start the release process...
Don't know: in what class would you publish them? If they have to be
part of the interface then why not to add specific/typed setters for
each property? Instead if they have to be in the implementation I
don't think it worth using them as (if used) it would break even more
the service locator pattern.
Stefano
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
hi there,
i think it would sense to expose those property names as public static
fields. are you guys ok with it? If so I will commit the this and
after that start the release process...
bye
norman
Am Montag, 18. Juli 2011 schrieb Stefano Bagnara <ap...@bago.org>:
> 2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
>> On Mon, 2011-07-18 at 13:08 +0200, Stefano Bagnara wrote:
>>> Hi all,
>>>
>>> I updated jDKIM and it worked fine. I'm also trying to update another
>>> local project I have depending on mime4j trunk and I'm a bit lost
>>> about using a custom DecodeMonitor via dom.
>>> Here is the code I'm updating...
>>> ----
>>> factory = MessageServiceFactory.newInstance();
>>> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
>>> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
>>> MessageBuilder builder = factory.newMessageBuilder();
>>> builder.setDecodeMonitor(new CheckHandlerDecodeMonitor(eh));
>>> Message message = builder.parseMessage(is);
>>> -----
>>>
>>> setDecodeMonitor is not anymore exposed by the interface. I thought we
>>> discussed this very thing in past but I run some search with no
>>> success (so probably my memory is leaking).
>>> Is this feature exposed in a different way that I can't currently find?
>>> Or otherwise, how can we expose it again?
>>> - one more possibile attribute in the factory?
>>
>> That'd be my preferred choice.
>
> Done
>
>>> - adding parseMessage(InputStream,DecodeMonitor) and
>>> parseHeader(InputStream,DecodeMonitor) methods to the MessageBuilder?
>>> - simply publishing the setDecodeMonitor from MessageBuilderImpl to
>>> MessageBuilder?
>>
>> Setter methods in an interface that essentially represents a strategy
>> does not sound right to me.
>
> My main concern is that "dom" api is a lot limited unless you use
> "setAttribute" with some magic parameter that you expect to work like
> our default implementation does. This doesn't sound good to me for an
> API.
>
> That said I'm fine with a 0.7 release from current trunk. It's not
> perfect, but a step forward from previous releases.
>
> So, I'll be very happy to vote as soon as Norman will roll it!
>
> Stefano
>
>> Oleg
>>
>>
>
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
2011/7/18 Oleg Kalnichevski <ol...@apache.org>:
> On Mon, 2011-07-18 at 13:08 +0200, Stefano Bagnara wrote:
>> Hi all,
>>
>> I updated jDKIM and it worked fine. I'm also trying to update another
>> local project I have depending on mime4j trunk and I'm a bit lost
>> about using a custom DecodeMonitor via dom.
>> Here is the code I'm updating...
>> ----
>> factory = MessageServiceFactory.newInstance();
>> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
>> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
>> MessageBuilder builder = factory.newMessageBuilder();
>> builder.setDecodeMonitor(new CheckHandlerDecodeMonitor(eh));
>> Message message = builder.parseMessage(is);
>> -----
>>
>> setDecodeMonitor is not anymore exposed by the interface. I thought we
>> discussed this very thing in past but I run some search with no
>> success (so probably my memory is leaking).
>> Is this feature exposed in a different way that I can't currently find?
>> Or otherwise, how can we expose it again?
>> - one more possibile attribute in the factory?
>
> That'd be my preferred choice.
Done
>> - adding parseMessage(InputStream,DecodeMonitor) and
>> parseHeader(InputStream,DecodeMonitor) methods to the MessageBuilder?
>> - simply publishing the setDecodeMonitor from MessageBuilderImpl to
>> MessageBuilder?
>
> Setter methods in an interface that essentially represents a strategy
> does not sound right to me.
My main concern is that "dom" api is a lot limited unless you use
"setAttribute" with some magic parameter that you expect to work like
our default implementation does. This doesn't sound good to me for an
API.
That said I'm fine with a 0.7 release from current trunk. It's not
perfect, but a step forward from previous releases.
So, I'll be very happy to vote as soon as Norman will roll it!
Stefano
> Oleg
>
>
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-07-18 at 13:08 +0200, Stefano Bagnara wrote:
> Hi all,
>
> I updated jDKIM and it worked fine. I'm also trying to update another
> local project I have depending on mime4j trunk and I'm a bit lost
> about using a custom DecodeMonitor via dom.
> Here is the code I'm updating...
> ----
> factory = MessageServiceFactory.newInstance();
> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
> MessageBuilder builder = factory.newMessageBuilder();
> builder.setDecodeMonitor(new CheckHandlerDecodeMonitor(eh));
> Message message = builder.parseMessage(is);
> -----
>
> setDecodeMonitor is not anymore exposed by the interface. I thought we
> discussed this very thing in past but I run some search with no
> success (so probably my memory is leaking).
> Is this feature exposed in a different way that I can't currently find?
> Or otherwise, how can we expose it again?
> - one more possibile attribute in the factory?
That'd be my preferred choice.
> - adding parseMessage(InputStream,DecodeMonitor) and
> parseHeader(InputStream,DecodeMonitor) methods to the MessageBuilder?
> - simply publishing the setDecodeMonitor from MessageBuilderImpl to
> MessageBuilder?
Setter methods in an interface that essentially represents a strategy
does not sound right to me.
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Stefano Bagnara <ap...@bago.org>.
Hi all,
I updated jDKIM and it worked fine. I'm also trying to update another
local project I have depending on mime4j trunk and I'm a bit lost
about using a custom DecodeMonitor via dom.
Here is the code I'm updating...
----
factory = MessageServiceFactory.newInstance();
factory.setAttribute("StorageProvider", new MemoryStorageProvider());
factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
MessageBuilder builder = factory.newMessageBuilder();
builder.setDecodeMonitor(new CheckHandlerDecodeMonitor(eh));
Message message = builder.parseMessage(is);
-----
setDecodeMonitor is not anymore exposed by the interface. I thought we
discussed this very thing in past but I run some search with no
success (so probably my memory is leaking).
Is this feature exposed in a different way that I can't currently find?
Or otherwise, how can we expose it again?
- one more possibile attribute in the factory?
- adding parseMessage(InputStream,DecodeMonitor) and
parseHeader(InputStream,DecodeMonitor) methods to the MessageBuilder?
- simply publishing the setDecodeMonitor from MessageBuilderImpl to
MessageBuilder?
Or instead you think this feature should not be anymore exposed via
the dom api at all?
Stefano
2011/7/18 Norman Maurer <no...@apache.org>:
> Am 18.07.2011 11:26, schrieb Oleg Kalnichevski:
>>
>> On Sun, 2011-07-17 at 21:50 +0200, Norman Maurer wrote:
>>>
>>> Hi Oleg,
>>> is this up-to-date for 0.7 ?
>>>
>>> http://svn.apache.org/viewvc/james/mime4j/trunk/RELEASE_NOTES.txt?view=markup
>>>
>>> I guess no, as it was last updated 14 Month ago. Would be possible for
>>> (and Stefano) to update to reflect latest API changes ?
>>>
>>> Thanks,
>>> Norman
>>>
>>> Ps: After that I will start the RELEASE process
>>>
>> I updated the release notes with the bits I felt deserved a mention. I'd
>> be nice, though, if Stefano could also chip in. I'd also be nice if an
>> native English speaker could proof-read the notes.
>>
>> Cheers
>>
>> Oleg
>
> Thanks Oleg,
>
> I will now wait for Stefano to chime in.
>
> Bye,
> Norman
>
>
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@apache.org>.
Am 18.07.2011 11:26, schrieb Oleg Kalnichevski:
> On Sun, 2011-07-17 at 21:50 +0200, Norman Maurer wrote:
>> Hi Oleg,
>> is this up-to-date for 0.7 ?
>> http://svn.apache.org/viewvc/james/mime4j/trunk/RELEASE_NOTES.txt?view=markup
>>
>> I guess no, as it was last updated 14 Month ago. Would be possible for
>> (and Stefano) to update to reflect latest API changes ?
>>
>> Thanks,
>> Norman
>>
>> Ps: After that I will start the RELEASE process
>>
> I updated the release notes with the bits I felt deserved a mention. I'd
> be nice, though, if Stefano could also chip in. I'd also be nice if an
> native English speaker could proof-read the notes.
>
> Cheers
>
> Oleg
Thanks Oleg,
I will now wait for Stefano to chime in.
Bye,
Norman
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2011-07-17 at 21:50 +0200, Norman Maurer wrote:
> Hi Oleg,
> is this up-to-date for 0.7 ?
> http://svn.apache.org/viewvc/james/mime4j/trunk/RELEASE_NOTES.txt?view=markup
>
> I guess no, as it was last updated 14 Month ago. Would be possible for
> (and Stefano) to update to reflect latest API changes ?
>
> Thanks,
> Norman
>
> Ps: After that I will start the RELEASE process
>
I updated the release notes with the bits I felt deserved a mention. I'd
be nice, though, if Stefano could also chip in. I'd also be nice if an
native English speaker could proof-read the notes.
Cheers
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@googlemail.com>.
Hi Oleg,
is this up-to-date for 0.7 ?
http://svn.apache.org/viewvc/james/mime4j/trunk/RELEASE_NOTES.txt?view=markup
I guess no, as it was last updated 14 Month ago. Would be possible for
(and Stefano) to update to reflect latest API changes ?
Thanks,
Norman
Ps: After that I will start the RELEASE process
2011/7/15 Oleg Kalnichevski <ol...@apache.org>:
> On Fri, 2011-07-15 at 14:42 +0200, Norman Maurer wrote:
>> Hi there,
>>
>> I could act as release manager if you like...
>>
>
> That'd be great!
>
> Oleg
>
>
>
Re: As far as I am concerned 0.7 is ready
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2011-07-15 at 14:42 +0200, Norman Maurer wrote:
> Hi there,
>
> I could act as release manager if you like...
>
That'd be great!
Oleg
Re: As far as I am concerned 0.7 is ready
Posted by Norman Maurer <no...@apache.org>.
Hi there,
I could act as release manager if you like...
Bye,
Norman
Am 15.07.2011 14:32, schrieb Oleg Kalnichevski:
> Folks,
>
> As far as I am concerned 0.7 is ready. At this point I do not think
> there is really that much more I could contribute.
>
> I am stepping aside and letting someone else take over from this point
> on.
>
> Cheers
>
> Oleg
>