Robert Burrell Donkin ha scritto:
On Mon, Jul 21, 2008 at 4:06 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Mon, Jul 21, 2008 at 3:09 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
i'm dispirited because i finally have a day off to catch up on JAMES
stuff and (yet again) i find that i can't work on IMAP because MIme4J
can't be built
Just build it anyway. You can ignore failures because they should not be
*new* bugs, but older bugs that simply have a proving test now.
ignoring failures is a bad idea: it's too easy to introduce
regressions into the Mime4J codebase.
I'm not sure I understand. The failures I see are "known" and are not
regressions (they are there to prove we have bugs, we have since more than
10 days). If you see more failures just report them: I'm sorry I can't fix
issues I don't see ;-)
unless mime4j is build and integration regularly with JAMES, it's easy
for regressions in mime4j to break JAMES
Sure but this does not apply to new test messages added to prove
existence of bugs: they did not change the behaviour so they can't
introduce regression ;-)
Unfortunately we removed many messages from the test suite so we had a
less
complete test suite in the current implementation. This led to
regression,
and this simply happens (I'm not telling that it's your fault).
i'm not bothered about fault finding: i'm just concerned that Mime4j is
broken
I'm concerned too. Should we revert Niklas fix until we have a better
solution? I don't think so.
I don't think that the mime4j we had previously (not handling
quoted-printable text) was any better than what we have now.
If you want tests to pass then IMHO the best option ATM is to fix the quoted
printable issue, or, if noone can deal with this in short time to simply
comment the 3 failures in MessageWriteToTest.
i'm taking a look at it now. the problem with having lots of failing
tests around is that it makes regression testing harder.
I recently changed the testsuites to provide more visual feedback when
checking msg files and added the ability to run single msg checks, too.
Furthermore the test failures (for the ex. testParse method) are now
separated for each msg file.
So it should not be hard to see what is failing and why.
An issue was about boundary handling and the regression was against what
the
RFC document (so it was documented), but again, it is not important to
understand who is the author of the mistake: if someone do things is for
sure more probable that he also does mistakes. Who does nothing does not
mistake too.
The 3 test failing in MessageWriteToTest are simply failing because their
expected result is probably bad from an RFC compliance point of view.
if the expected result is wrong then it should be fixed. if the
expected result is right then the code has regressed and should be
fixed.
Expected result expected non encoded spaces.
There was no encoding support in previous mime4j (BUG: MIME4J-59) so the
code was not used there.
If we fix MIME4J-59 but we don't fix MIME4J-62 then we have to change the
expected result.
Furthermore even if we change the expected result there is currently an
issue with a CRLF added to the end of that part. This is another issue that
should be investigated to make the test suite pass.
I don't think this can be considered a regression (MIME4J-62), anyway: this
bug has been created by a much bigger bug. Previously it was working because
of the bug, and it was a concidence because it only worked because the
encoded text has no char to be escaped by the QP algorythm.
MIME4J-59 instead is a regression.
it's looks a bit more complex: the codec was intentionally designed
for use only with non-textual attachments. (IIRC there is different
guideance for that.)
Ok. Let's reword it, then: How should we deal with the very commons
quoted-printable text/plain parts?
IMHO even if the tests previously passed we had a problematic test suite
because MessageWriteToTest expected a behaviour that mime4j did not
support. The tests was not failing simply because of another bug
(MIME4J-59). See my recent comment to MIME4J-62 for details.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
