Skip to main content

A better tool integration API for XJC

2 replies [Last post]
kohsuke
Offline
Joined: 2003-06-09
Points: 0

the JAXB RI 2.0 EA includes an improved tool integration API for jaxb
workshop. Take a look at

public static int Driver.run(String[] args, XJCListener listener)

and com.sun.tools.xjc.XJCListener. Most of the errors are reported as
SAXParseException.

Based on an early feedback from Kirill, I modified it and added a new
callback to report a file generated from XJC.

This new callback is already in the repository, and it will be available
in the next weekly drop.

Please send us the feedback on this. Once it stabilizes, I plan to maintain
this interface in the future versions of XJC.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kirillcool
Offline
Joined: 2004-11-17
Points: 0

A small problem still remains. The SAXException contains the filename, with %20 replacing each space character. I suppose that the new callback provides the filename without the space (at least it was so in the old message() callback).

In this case i have to manually replace %20 by space to match the filenames.

In addition, it would be nice to have an additional callback that provides a name of each XSD file that is being processed. Arguably this can be taken from xsom model (creating a listener and storing set of all filenames from Locator), but this will involve an additional pass on all the schemas. This way you can provide me (and other interested parties) a list of all input (in addition to all output) files that were involved in the process.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

The system IDs of SAXParseException is a URL, in which space needs to be escaped. If you know that the URL is a file:// URL, a part of the conversion from URL to file name includes de-escaping %20.

The generatedFile callback returns a file name, and in file names spaces are not escaped.

So I think it's just following what needs to be done. Those two are different things. It's unfortunate that you have to handle them differently, but I think it's still better than returning file names as URLs.

> In addition, it would be nice to have an additional callback that provides a name of each XSD file that is being processed.

I think this can be done. Let me see.