XMLC 2.3.1 is out (for real this time)

[Jacob Kjome]

I'm happy to announce the release of XMLC-2.3.1!

Users of XMLC 2.2.xx are encouraged to upgrade to XMLC 2.3.1, though be sure to
read xmlc-2-3-release-note.html and xmlc-2-3-1-release-note.html before doing so.
 Enjoy!

Download at:
http://forge.objectweb.org/projects/xmlc/


XMLC 2.3.1 includes all relevant features/enhancements/fixes in XMLC 2.2.17 plus...

Bug Fixes...

- Got rid of last remnants of "org.enhydra.apache" and "org/enhydra/apache" namespaces

- Fixed NullPointerException in OutputOptions.toString()

- Fixed expansion of LazyEntityReference and LazyEntity in Lazydom

General Updates...

- Cleaned up org.enhydra.xml.xmlc.parsers.xerces.XercesHTMLDOMParser

- Updated to Xerces 2.9.1 and NekoHTML 1.9.8


See xmlc-2-3-1-release-note.html for more info


--
Barracuda mailing list
Barracuda@...
http://www.ow2.org/wws/lists/projects/barracuda

[Franck Routier]

Hi Jake,

[So if I understand right, you changed your ClosingInputStreamReader to
get around the bug in NekoHTML ? Taht's cheating :) ]


Well, my question was about Barracuda and a unit test that a been
failing for a long long time here...

TestXmlcUtilsCreate.testCreate() is failing.

What it does exactly is :

XmlcUtils xmlcUtils = XmlcUtils.create();

assertEquals("Default create should return a default implementation",
DefaultXmlcUtilsImpl.class, xmlcUtils.getClass());

It fails here.

It is failing because package org.barracudamvc.taskdefs.Localize does:

System.setProperty(XmlcUtils.DEFAULT_UTILS_CLASS_KEY,
LocalizeXmlcUtilsImpl.class.getName());

As Localize is used in the tests before TestXmlcUtilsCreate, System
property is set, and XmlcUtils.create() returns
LocalizeXmlcUtilsImpl.class. And test fails.

So my question is, should the test be updated, or should
org.barracudamvc.taskdefs.Localize be changed (I don't understand whiy
it wants to set the property), or ???


Franck







--
Barracuda mailing list
Barracuda@...
http://www.ow2.org/wws/lists/projects/barracuda

[Jacob Kjome]

On Wed, 23 Jul 2008 15:41:21 +0200
  Franck Routier <franck.routier@...> wrote:
> Hi Jake,
>
> [So if I understand right, you changed your ClosingInputStreamReader to
> get around the bug in NekoHTML ? Taht's cheating :) ]
>

Yeah, I know :-)  But the primary developer of NekoHTML convinced me that
CosingInputSource reader and inputstream implementations weren't respecting
their respective contracts.  By changing the XMLC code, XMLC will work with
both current and prior versions of NekoHTML; that is, not blow chunks on files
with '\n' or '\r' line endings.  Note that prior versions of XMLC (before
2.2.17 and 2.3.1) didn't make much use of ClosingInputSource, so they wouldn't
run into the issue anyway.  It wasn't until I made use of it to ensure that
streams get closed to avoid locking source files at runtime that this became
an issue, hence the long delay in releasing 2.2.17 and 2.3.1.

>
> Well, my question was about Barracuda and a unit test that a been
> failing for a long long time here...
>
> TestXmlcUtilsCreate.testCreate() is failing.
>
> What it does exactly is :
>
> XmlcUtils xmlcUtils = XmlcUtils.create();
>
> assertEquals("Default create should return a default implementation",
> DefaultXmlcUtilsImpl.class, xmlcUtils.getClass());
>
> It fails here.
>
> It is failing because package org.barracudamvc.taskdefs.Localize does:
>
> System.setProperty(XmlcUtils.DEFAULT_UTILS_CLASS_KEY,
> LocalizeXmlcUtilsImpl.class.getName());
>
> As Localize is used in the tests before TestXmlcUtilsCreate, System
> property is set, and XmlcUtils.create() returns
> LocalizeXmlcUtilsImpl.class. And test fails.
>
> So my question is, should the test be updated, or should
> org.barracudamvc.taskdefs.Localize be changed (I don't understand whiy
> it wants to set the property), or ???
>

I would suggest commenting out that test.  It's really one that should be
migrated to the XMLC codebase at some point, so just comment it out, don't
delete it.  I meant to do this a while back, but got sidetracked.  The whole
design is kind of hoakie, but it is what it is and it is necessary for the
Localize task to set that property, otherwise the default Xmlc task will get
loaded instead of Localize, which is what is needed for Barracuda builds.

I had been thinking about moving the Localize stuff over to XMLC in order to
give all XMLC users, not just Barracuda users, a way to do localization. 
However, there are some runtime Barracuda-isms that are required to enable
localization which make it not so generalizable for XMLC's purposes.  So, I
started looking into some other more standard alternatives.  I did a whole
bunch of research and then kind of ran out of gas and time.  I'll have to see
if I archived the research?  I still think it would be valuable to have a
standard XMLC-based localization mechanism, which would hopefully make the
Localize task irrelevant.

Jake

>
>Franck




--
Barracuda mailing list
Barracuda@...
http://www.ow2.org/wws/lists/projects/barracuda