> 1. Neglect all options not available in the "standard" which would > probably be the idl2java from Sun's SDK. Those using other vendors > tools won't like this.
I don't like this approach, cause it doesn't allow to use specific ORB features, which can be critical for developers. > 2. Add all options possibly there. A maintenance nightmare. I agree, maintenance cost is not acceptable. BTW where is third bullet? :o) > 4. Have only one option at all - for the command line. I don't like this one .... > 5. Invent magic properties to trigger some options. This is what the > current jikes implementation does to get additional warnings or error > messages in emacs compatible format. I would rather not use properties > at all. All compiler specific features resides inside the code and cannot be configured during the compile time. > 6. Have individual attributes for all common options and a single > attribute (additionaloptions or so) to be parsed (or ignored) by the > specific implementation. I see this approach like abstract idlToJava task which has to be extended by specific implementation. It has basic common options and parameters: - source idl file - destination directory - turn on/off the generation POA stubs and skeletons - define the symbol - include path - turn on/off warning - verbose mode switch - version and, of course, virtual launching facility: - execute If specific ORB doesn't support some of this switches - simply ignore them. If developer will decide to make his IDL compilation vendor independent he or she will has to use only standard options. All realizations has to extend abstract idlToJava. In every realization can be realized its specific options. But if we use non-standard option by one idl compiler option and then try to switch compilers we have no guaranties to compile it without build errors (this is the price - build parsing error which indicate unsupported by ORB or incorrect option). Selected idl compiler is recognized from java 'build.compiler.idl' option. The run-time schema seems to me like: 1) idlToJava static constructor recognize selected implementation by examining property and instantiate proper descendant class. 2) pass all options from idlToJava task directly to instance of class received on step 1. 3) if everything okay it is time to execute the idl compiler Described solution can be interesting approach for the Javac task too. That's all I wanted to say at the moment. Thanks, Vitaly __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
