Public Member Functions
	XmlIdlCompiler ()
void	compile_file (String file_name, IdlParser parser)
Static Public Member Functions
static void	main (String[] args)
Static Public Attributes
static final String	PROP_DO_GENERATE_COMP_HELPERS = "alma.acs.tools.comphelpergen.doGenerate"
static final String	PROP_COMP_HELPERS_OUTDIR = "alma.acs.tools.comphelpergen.outRootDir"
Static Protected Attributes
static IdlCompiler	s_idlCompiler = new IdlCompiler()

Detailed Description

Main class of the ACS IDL compiler that produces interfaces, structs, and holders for use with XML binding classes. The generated code will be similar but different from the output of a regular CORBA IDL compiler. IDL interfaces, structs, etc. that contain a field or parameter of type XmlEntityStruct will be compiled into source code that contains a corresponding XML binding class.

In collaboration with the other classes from this package, this class performs the following steps for each IDL file specified:

parses the IDL file (using an org.openorb.compiler.parser.IdlParser). The intermediate result is a tree of org.openorb.compiler.object.IdlObject nodes.
identifies IDL typedefs for the type XmlEntityStruct, e.g. the definition of the type SchedBlock. (see IdlTreeManipulator#findXmlTypedefNodes)
marks the nodes in the parse tree that are affected by the XML entity types (using IdlTreeManipulator#findXmlEntityNodes). This ensures that later we don't generate code that would be functionally identical to the code generated by a standard IDL compiler.
Note that the identification of parse tree nodes works upward-recursive: for example, if an IDL struct contains another struct which has a member of type SchedBlock, then both IDL structs will get marked.
translates the relevant nodes of the manipulated IDL parse tree into Java code (using JavaGenerator#translateData).
Note that the logic of mapping IDL to Java and the code generation itself are not separated.
optionally runs the code generator for component helper class templates, see alma.tools.idlgen.comphelpgen.ComponentHelperGeneratorProxy and alma.acs.tools.comphelpergen.CompHelperGenerator.
Information about (component) interfaces and Java packages is transmitted as an XML string that conforms to the schema HelperInfo in the package alma.acs.tools.comphelpergen.

Parameters and properties:

Takes all command line arguments that are valid for org.openorb.compiler.IdlCompiler, although some of them don't apply and will be ignored.
Interesting for tracing is -verbose.
The property ACS.idl2jbind specifies the mappings from typedef'd XmlEntityStructs to Java binding classes.
For example, the value "<code>SchedBlock=alma.xmljbind.test.schedblock.SchedBlock; ObsProject=alma.xmljbind.test.obsproject.ObsProject</code>" instructs the compiler to use the Java class alma.xmljbind.test.schedblock.SchedBlock whereever an XmlEntityStruct typedef'd to SchedBlock is found.
Two properties control the optional invocation of the code generator for component helper classes:
- alma.acs.tools.comphelpergen.doGenerate: if true, the ACS IDL compiler will run the generator after compiling an IDL file. See alma.tools.idlgen.comphelpgen.ComponentHelperGeneratorProxy.
- alma.acs.tools.comphelpergen.outRootDir specifies the directory under which the component helper classes will be generated according to their Java packages.

In order to keep things simple, the implementation uses the OpenORB IDL compiler (org.openorb.compiler.IdlCompiler and related classes) whereever this is possible. No OpenORB code is modified; this goal results in some less intuitive handling of parse tree nodes, since new behavior could not be attached to the existing classes. On the other hand, we won't have to insert our patches into any new version of OpenORB that we might want to use in the future.

A half-inspired attempt has been made to pave the road for code generation for languages other than Java. The tree manipulations could also be used by other code generators. For Java we reused OpenORB's implementation of the IDL2Java mapping logic (see JavaGenerator), but similar generators for other languages would be much more complex.

Remark on the proprietary code generation strategy used: Since OpenORB does not separate IDL2Java mapping logic from Java code generation, we can't use any standard code generation framework without reimplementing the IDL2Java logic ourselves. The choice was to accept being different from other ACS code generators, with the advantage of not writing lots of new code.