Oh, and don't check in the Eclipse project files. I'll tweak my own and
check them in before the production release. Mine are currently set to
use the same output directories as the build script, but now that I
think about it perhaps it's better to use a separate bin directory. I
often use the Ant builds while I've got things open in Eclipse, and with
my current structure they step on each other; a separate directory would
eliminate that problem.
- Dennis
Dennis Sosnoski wrote:
The failing test was partially the closeNamespaces() error and
partially that you were beginning a new start tag without closing the
one you'd started previously. There's very little error checking in
this code, since it's designed mainly for internal framework use.
I agree the Eclipse 3.1 warnings are great! I'd just converted over to
64-bit Linux a couple of weeks ago and upgraded to Eclipse 3.1 at the
same time. I ran into problems using Eclipse with the Sun 1.5 JDK on
my 64-bit Linux, but once I changed the default JDK over to Blackdown
everything works well. This problem shows that I should take the time
to investigate all the warnings Eclipse generates and either eliminate
the unused variables or use them as originally intended.
- Dennis
Andreas Brenk wrote:
The first cause for broken test cases was my constructur usage. I knew
my implementation would not touch the first two namespace array indices
so I just used a zero length String array in the tests.
The second was a change in return values if no extension namespaces are
defined. I returned a zero-length array, the shared code returns null.
So I had to change some assertions.
There's still one failing test method and I fear the cause doesn't lie
in my responsibility but in XMLWriterNamespaceBase's closeNamespaces().
The variable "priors" is never used in that method block (a nice warning
new in Eclipse 3.1) and so I think namespace prefixes that change are
not properly restored. My first tries to fix that were not successful.
By the way: Is it okay, if I check in the Eclipse project files?
(.project, .classpath and .settings/* as well as a .cvsignore for "bin")
Regards,
Andreas
Dennis Sosnoski wrote:
Sure, taking the discussions to jibx-devs is fine. I'd love to see
people implement the same sort of output adapters for other document
models (as well as input adapters). What was the cause of the broken
test cases?
- Dennis
Andreas Brenk wrote:
Thanks! I already fixed the test case to work (again) as expected.
Should we continue further discussion on jibx-devs?
Andreas
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
