My sense is that none of the tools is a "perfect fit" out of the
box, so it's just a matter of working through the necessary
customizations. I think I'm quite close to being satisfied with XMLBeans
-- I suspect I just need to straighten out our Geronimo namespace and then
wait for the XMLBeans project to put something in the Maven repository.
But just to state my requirements, here's what I can think up off
the top of my head:
- the tool must be able to process the full set of J2EE XSDs, including
EAR, Web, JSP, Taglib, EJB, RAR, web services, web services client,
application client
- we must be able to customize the translation of XML elements to POJO
packages & class names
- the tool should be reasonably fast (fraction of a second to parse DD)
- the smaller the tool JAR the better
- the tool should not rely on any 3rd party JARs/libraries, including
any specific XML parser
- the generated code should have getters and setters returning strings
for elements that just contain text values (i.e. getEjbName() for the
"ejb-name" child of an EJB element)
- XPath support is a big bonus
- the tool must be able to read and write DDs from the command-line
deployer without any onerous configuration
- the tool must write DDs with namespace indicators (reading and then
rewriting a DD should not lose information in the document element or
header)
- the tool should write human-readable DDs (not all on one line, use
indentation, not unnecessary CDATA wrappers)
- ideally, the tool would not refuse to load an incomplete document (such
as omitting the version attribute in the document element), such that we
could load a EJB 2.0 DD with the code generated for EJB 2.1 (not sure how
realistic this is)
- the tool should be available via maven, so we don't need to manually
add the JAR to our build tree
- ideally, the tool would generate base classes or interfaces for
elements with common content groups (JNDI environment refs group,
description group)
Aaron
On Wed, 8 Oct 2003, Jacek Laskowski wrote:
> > Have we considered the use of JiBx (http://jibx.sourceforge.net/)? I'm
> > seeing small reservations from everyone who looks at XMLBeans. Why not
> > consider other tools that are very well suited to the job?
>
> That's then the first cadidate or the second assuming XMLBeans was the
> first. We've got two on the table, what about requirements? I don't
> remember what were the problems with the tools, and although I would
> probably be able to find it out very easily in the archive, I think that
> after some time we could change out expectations as well. So, please let
> me know what we need and Castor or XMLBeans don't provide?
