[
https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795631#action_12795631
]
Stefano Bagnara commented on MIME4J-156:
----------------------------------------
Current status:
field is clean
field.impl contains the field parser implementations and field implementations.
message is clean
message.impl contains classes depending on field.impl and parser
Todo:
field.address contains both api and impl code (static methods).. needs the same
treatment done to field.
parser should be split in 2, moving code with no dependencies into a subpackage
(or viceversa, creating an "impl" there, too). descriptor package should be
merged to parser (and then splitted between api/impl).
util/codec/io needs some review. e.g: io is only used in parser, maybe it
should be moved to parser.io to make it more clear in future.
> DOM (message) classes should not be implementation specific. Move
> implementation to a different package (message.impl)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MIME4J-156
> URL: https://issues.apache.org/jira/browse/MIME4J-156
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 0.8
>
>
> Let's start "splitting" message between generic interfaces/abstract classes
> and specific implementations based on mime4j modules (parser).
> Abstract classes vs Interface is a tricky issue wrt api. I think the
> important thing now is to separate implementation details from design/api.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
