james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: As far as I am concerned 0.7 is ready
Date Wed, 20 Jul 2011 06:28:06 GMT

I upgraded imap and mailbox yesterday on my mac and everything still work.

So I think we are ready,

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<apache@bago.org>:
>> 2011/7/19 Oleg Kalnichevski<olegk@apache.org>:
>>> On Mon, 2011-07-18 at 22:18 +0200, Stefano Bagnara wrote:
>>>> 2011/7/18 Oleg Kalnichevski<olegk@apache.org>:
>>>>> On Mon, 2011-07-18 at 21:48 +0200, Stefano Bagnara wrote:
>>>>>> 2011/7/18 Norman Maurer<norman.maurer@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

View raw message