However the point of these beans is to act as the POJO API for working with the XML config files. So I don't see much value in using the beans without the XML config files. So I don't see this extra-jar dependency as a big issue. Even if you were not using an XML config file, the XPath & XSD validation is extremely useful too.
I understand, though I would like to find a common binding framework which the entire project could use.
I'm just focussing right now on 1 use case - to find an XML binding tool to handle all the various J2ee schemas. Today the only solution that works is XMLBeans
Take for example if there was a WAR deployer which took one of these objects (not a URL to an XML file or whatever), then you could programatically install web-apps with out having to deal with XML at all.
When would you ever use the WAR deployer without XML? i.e. the WAR deployer has to read the XML config files, so xmlbeans.jar would already be on the classpath. The person programmatically installing a web-app wouldn't really need to worry about this dependency - since it would already be there. To compile the code to use the deployment beans you wouldn't have a dependency on xmlbeans.jar. Plus with XMLBeans its easy to validate that the beans really match the schema - whether your using an XML config file or not.
Like I've said several times already, XMLBeans solves the use case I've described just fine. I can't imagine a use case where anyone would use these beans without at least allowing for XML config files to be used (whether a developer uses them or not). So saving this 1 jar dependency doesn't seem very useful to me.
It sounds like this is possible with XMLBeans, though it would still be better IMO if it XML was not a dependency, so for embedded solutions which do not need or want any XML processing we could drop those dependencies to provide a smaller footprint.
Am not sure its that big a deal right now - adding 1 extra jar to the container (which Castor would anyways). Plus right now XMLBeans is the only tool that can actually do the job. Until someone else can find another tool that works, there is no choice :)
James ------- http://radio.weblogs.com/0112098/
