You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/08/07 11:52:28 UTC
[mime4j] packages / MIME4J-51 (Was: what else need to be done)
Niklas Therning ha scritto:
> Stefano Bagnara wrote:
>> Niklas Therning ha scritto:
>>> Stefano Bagnara wrote:
>> [...]
>> Here is an updated summary of what are our current proposed solutions:
>>
>> A) vote down MIME4J-51 and revert the code change.
>> + least surprise
>> + no upgrading effort required
>> * parser is in main package
>> - not good package classification
>> - cyclic dependencies
>>
>> B) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.* (so
>> to bring parser classes in the main package).
>> + remove cyclic dependencies
>> + better packaging
>> * parser is in main package
>> - BodyDescriptor and MimeException are in a different package than
>> before (upgrading issue)
>> - MaximalBodyDescriptor is a different package than before
>> (upgrading issue, at least for james-server)
>>
>> C) leave everything as is in trunk (mime4j-51 applied!).
>> + remove cyclic dependencies
>> + better packaging
>> + better organization to host non parsing related code, too.
>> * parser is in the parser package
>> - most "public" classes are moved around (upgrading issue)
>> - main parser classes are in mime4j.parser instead of main.
>>
>> D) move ContentHandler, AbstractContentHandler, MimeStreamParser,
>> MimeTokenStream from parser to main:
>> + better packaging
>> * parser is in main package
>> - cyclic dependencies: introduce 6 new package cycles:
>> main => parser => descriptor => field.datetime.parser => main
>> main => parser => descriptor => field.mimeversion => main
>> main => parser => descriptor => field.structured => main
>> main => parser => descriptor => field.language => main
>> main => parser => descriptor => main
>> main => parser => mime4j
>> - MaximalBodyDescriptor is in a differet package (upgrading issue)
>> [...]
>> This is what I think should be used as starting point for a POLL
>> unless we find a better agreement, so, before going to a POLL (given
>> that Bernd say we should not use polls), can you tell if #3 would work
>> for you by fixing the "parser centrality" issue but not fixing the
>> "upgrading issue" ?
>
> I'm not following you here. Do you mean "C" when you say #3?
My bad!! The mail refactoring before posting gone wrong! I need explicit
type casting so refactoring can take care of updating my mail
automatically :-P
#3 should have been "B"...
>> The "D" option (your proposal) was not on discussion previously so I
>> can only tell what is my current understanding of what people would
>> support. Where I don't put more names is because I don't yet
>> know/understand their position wrt the given option. Of course this is
>> my personal feeling and while I only do my best to understand people I
>> may be wrong in interpreting ideas, so everyone is welcome to fix my
>> understanding.
>>
>> A. -0 bago
>> B. +0/+1 robert/oleg/bago/bernd.
>> C. +1 bago/robert -0.5 bernd/niklas
>> D. -0.5 bago, +1 niklas
>>
>> If you like "B" I think (based on the above "table" and
>> considerations) we could find consensus there, otherwise I would
>> prefer to go the poll way so we test for real what people think and we
>> don't have to go through my understanding.
>
> I've thought about these options and I think I can actually live
> happily! :) with "C". I understand why you want the parser package and
> after giving this a bit more thought I think it would be a good way of
> organizing the code. We will have to add the package documentation for
> the main package as Bernd suggested.
I added an overview.html file. I thought this is more appropriate than a
package documentation, ATM. It simply have some paragraph from our
website home including a link to the parser/MimeStreamParser and the
message/Message classes.
I'm not so good in english and I don't have the same mime4j knowledge
you may have, so please look at it and make any change you think is
needed :-) (or write them here and I'll take care of the commit)
Here (if last build on hudson is working) you see how the generated
javadocs looks like:
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
> I have two requests when it comes to "C":
>
> * move the *Descriptor classes from the main package to the descriptor
> package. It doesn't make sense to have a package named descriptor and
> then having some classes, so closely related to what's inside this
> package, outside of it. AFAICS this doesn't introduce any cycles. Please
> verify this because my JDepend skills are terrible. :)
You mean moving "BodyDescriptor", "ContentDescriptor" and
"MutableBodyDescritor" from main to descriptor, right? This sounds
great, no new cycles and indeed a better "class-tree" to "package"
classification!
I already committed it :-)
Here is the current package tree:
http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
> * Rename the stream package io. MimeTokenStream is a stream too. It's a
> bit confusing to me that it isn't in the stream package.
I agree.
I just committed a refactoring to make most of them extensions of
FilterInputStream as they all of them take an inputstream in the
constructor, so maybe streamfilters is the best one... I didn't convert
EOLConvertingInputStream because it introduce one more filter in between
and it's less easy to update, but it is a filter in facts.
I'm fine with "io" but maybe a better option would be
"streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris"
so to make it more descriptive. Opinions?
In the mean time I also created a message.storage package we discussed
in past so to remove some more utility classes from the util package.
ATM I have no solution (to the concern raised by Bernd and Robert) for
the remaining utils because each of them is used by almost every other
package we have:
http://people.apache.org/~bago/mime4j/mime4j-51/mime4j-utils.gif
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Oleg Kalnichevski ha scritto:
>> On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
>>> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org>
>>> wrote:
>>>> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>>>>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>>>>> so I'd like to push this a little to understand if we can complete
>>>>> this
>>>>> and avoid reverting this or releasing something in progress.
>>>>>
>>>>> AFAICT the only pending issue is the "stream" package.
>>>>>
>>>>> Niklas commented:
>>>>>> * Rename the stream package io. MimeTokenStream is a stream too. It's
>>>>>> a bit confusing to me that it isn't in the stream package.
>>>>> I replied:
>>>>>> I'm fine with "io" but maybe a better option would be
>>>>>> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris"
>>>>>> so to make it more descriptive. Opinions?
>>>>> My current preference is "streamfilter" (more descriptive than "io"
>>>>> but
>>>>> shorter than "filterinputstreams"), but I'm happy with any name.
>>>>>
>>>> +1 to renaming 'stream' as 'io'. We may end up having classes that are
>>>> related to IO but are not streams. IO sounds generic enough yet
>>>> descriptive.
>>> +1
>>>
>>
>> Folks
>>
>> As far as I can tell no one objects the idea. If I hear no complaints,
>> I'll go ahead and rename the package and close MIME4J-51 tomorrow.
>
> +1
I was on mime4j (for the LICENSE issue) now, so I simply stole this job
from you and did it :-)
Release time.... !!!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
Oleg Kalnichevski ha scritto:
> On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
>> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>>> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>>>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>>>> so I'd like to push this a little to understand if we can complete this
>>>> and avoid reverting this or releasing something in progress.
>>>>
>>>> AFAICT the only pending issue is the "stream" package.
>>>>
>>>> Niklas commented:
>>>>> * Rename the stream package io. MimeTokenStream is a stream too. It's
>>>>> a bit confusing to me that it isn't in the stream package.
>>>> I replied:
>>>>> I'm fine with "io" but maybe a better option would be
>>>>> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>>>> My current preference is "streamfilter" (more descriptive than "io" but
>>>> shorter than "filterinputstreams"), but I'm happy with any name.
>>>>
>>> +1 to renaming 'stream' as 'io'. We may end up having classes that are
>>> related to IO but are not streams. IO sounds generic enough yet
>>> descriptive.
>> +1
>>
>
> Folks
>
> As far as I can tell no one objects the idea. If I hear no complaints,
> I'll go ahead and rename the package and close MIME4J-51 tomorrow.
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
> >> About the repackaging (MIME4J-51) I think we almost have an agreement,
> >> so I'd like to push this a little to understand if we can complete this
> >> and avoid reverting this or releasing something in progress.
> >>
> >> AFAICT the only pending issue is the "stream" package.
> >>
> >> Niklas commented:
> >> > * Rename the stream package io. MimeTokenStream is a stream too. It's
> >> > a bit confusing to me that it isn't in the stream package.
> >>
> >> I replied:
> >> > I'm fine with "io" but maybe a better option would be
> >> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
> >>
> >> My current preference is "streamfilter" (more descriptive than "io" but
> >> shorter than "filterinputstreams"), but I'm happy with any name.
> >>
> >
> > +1 to renaming 'stream' as 'io'. We may end up having classes that are
> > related to IO but are not streams. IO sounds generic enough yet
> > descriptive.
>
> +1
>
Folks
As far as I can tell no one objects the idea. If I hear no complaints,
I'll go ahead and rename the package and close MIME4J-51 tomorrow.
Oleg
> >> If I understand correctly there is consensus about the parser package.
> >> The main concern remain from Bernd: are you happy with the javadoc
> >> solution (overview.html) and the current structure?
> >> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
> >>
> >>
> >> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
> >>
> >> Oleg, I hope this summary let you understand what is the current status
> >> of MIME4J-51 and the consensus around it.
> >>
> >> I leave to you the decision about releasing without the refactoring
> >> (revert MIME4J-51), release "as is", or see the answers about the
> >> "stream" package and "complete it" before releasing.
> >>
> >
> > In the worst case I see no harm in releasing things as they stand and
> > revisiting MIME4J-51 during the 0.5 development.
>
> +1
>
> release early, release often ;-)
>
> i see no reason why we can't push ahead quickly with a 0.5 once 0.4
> has been released. IMHO it should be easier to settled some arguments
> when we can use benchmarking.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>> so I'd like to push this a little to understand if we can complete this
>> and avoid reverting this or releasing something in progress.
>>
>> AFAICT the only pending issue is the "stream" package.
>>
>> Niklas commented:
>> > * Rename the stream package io. MimeTokenStream is a stream too. It's
>> > a bit confusing to me that it isn't in the stream package.
>>
>> I replied:
>> > I'm fine with "io" but maybe a better option would be
>> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>>
>> My current preference is "streamfilter" (more descriptive than "io" but
>> shorter than "filterinputstreams"), but I'm happy with any name.
>>
>
> +1 to renaming 'stream' as 'io'. We may end up having classes that are
> related to IO but are not streams. IO sounds generic enough yet
> descriptive.
+1
>> If I understand correctly there is consensus about the parser package.
>> The main concern remain from Bernd: are you happy with the javadoc
>> solution (overview.html) and the current structure?
>> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
>>
>>
>> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
>>
>> Oleg, I hope this summary let you understand what is the current status
>> of MIME4J-51 and the consensus around it.
>>
>> I leave to you the decision about releasing without the refactoring
>> (revert MIME4J-51), release "as is", or see the answers about the
>> "stream" package and "complete it" before releasing.
>>
>
> In the worst case I see no harm in releasing things as they stand and
> revisiting MIME4J-51 during the 0.5 development.
+1
release early, release often ;-)
i see no reason why we can't push ahead quickly with a 0.5 once 0.4
has been released. IMHO it should be easier to settled some arguments
when we can use benchmarking.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Aug 13, 2008 at 12:40, Stefano Bagnara <ap...@bago.org> wrote:
> The main concern remain from Bernd: are you happy with the javadoc
...it is more my opinion than a concern...
> solution (overview.html) and the current structure?
> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
+1, that's ok. Although the link doesn't work for me since I don't
have a login for Hudson yet. But thank god it's open source ;-)
It would be nice to have MimeTokenStream also mentioned, but I guess I
should volunteer to add that. (see note above :-))
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
> About the repackaging (MIME4J-51) I think we almost have an agreement,
> so I'd like to push this a little to understand if we can complete this
> and avoid reverting this or releasing something in progress.
>
> AFAICT the only pending issue is the "stream" package.
>
> Niklas commented:
> > * Rename the stream package io. MimeTokenStream is a stream too. It's
> > a bit confusing to me that it isn't in the stream package.
>
> I replied:
> > I'm fine with "io" but maybe a better option would be
> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>
> My current preference is "streamfilter" (more descriptive than "io" but
> shorter than "filterinputstreams"), but I'm happy with any name.
>
+1 to renaming 'stream' as 'io'. We may end up having classes that are
related to IO but are not streams. IO sounds generic enough yet
descriptive.
> If I understand correctly there is consensus about the parser package.
> The main concern remain from Bernd: are you happy with the javadoc
> solution (overview.html) and the current structure?
> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
>
>
> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
>
> Oleg, I hope this summary let you understand what is the current status
> of MIME4J-51 and the consensus around it.
>
> I leave to you the decision about releasing without the refactoring
> (revert MIME4J-51), release "as is", or see the answers about the
> "stream" package and "complete it" before releasing.
>
In the worst case I see no harm in releasing things as they stand and
revisiting MIME4J-51 during the 0.5 development.
> If you decide anything and need help with action (e.g: revert the code)
> just let me know. If you need help with our "tricky" m2 setup you can
> find me in #james channel @freenode (and many IMs network.. ).
>
Thanks. I appreciate that.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
About the repackaging (MIME4J-51) I think we almost have an agreement,
so I'd like to push this a little to understand if we can complete this
and avoid reverting this or releasing something in progress.
AFAICT the only pending issue is the "stream" package.
Niklas commented:
> * Rename the stream package io. MimeTokenStream is a stream too. It's
> a bit confusing to me that it isn't in the stream package.
I replied:
> I'm fine with "io" but maybe a better option would be
> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
My current preference is "streamfilter" (more descriptive than "io" but
shorter than "filterinputstreams"), but I'm happy with any name.
If I understand correctly there is consensus about the parser package.
The main concern remain from Bernd: are you happy with the javadoc
solution (overview.html) and the current structure?
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
Oleg, I hope this summary let you understand what is the current status
of MIME4J-51 and the consensus around it.
I leave to you the decision about releasing without the refactoring
(revert MIME4J-51), release "as is", or see the answers about the
"stream" package and "complete it" before releasing.
If you decide anything and need help with action (e.g: revert the code)
just let me know. If you need help with our "tricky" m2 setup you can
find me in #james channel @freenode (and many IMs network.. ).
Here is a tutorial from Norman describing how we released mime4j 0.3:
http://svn.apache.org/repos/asf/james/project/trunk/HOWTO_RELEASE.txt
I just fixed a couple of issues in the generated website (bad refereces
to the apidocs). I saw the "news" page would require some changes but I
don't know what to write. Maybe we can include the release notes text
there once you prepared it.
Here is the current "News and Status" page as built by Hudson:
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/status.html
You can also see I added a "Related Projects" menu and linked
"httpmime". Please check it is ok for you and do your changes if you
have preferred land pages.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org