What's the problem of using idlj instead of writing our own...? As anders mentioned, if we can workaround its limitation, then I would suggest using that...
Is the problem that it cannot be easily extended to solve any bugs that might arise? - Balaji -----Original Message----- From: Lars Kühne [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 5:08 PM To: [email protected] Subject: Re: Specs, IDL compiler thoughts Dain Sundstrom wrote: > On Jun 24, 2006, at 2:43 PM, Alan D. Cabrera wrote: > >> Anders Hessellund Jensen wrote: >>> Sooner or later, we need to get rid of all our generated java >>> classes and start generating these classes from the IDL sources. >>> >>> We therefore need to decide which IDL compiler to use for this. >>> >>> We have had some bad experiences with JacORB >>> (http://issues.apache.org/jira/browse/YOKO-34), so this time i >>> suppose we stick to the SUN-provided idlj compiler. >>> >>> Geronimo has a CORBA 3.0 spec project. I think it would be >>> reasonably easy to adapt these files to work with idlj. IMO, this >>> would be the best approach. >>> >>> One issue with idlj is that it does not have support for the "local" >>> keyword. I guess we will have to live with this limitation, and >>> treat all interfaces as non-local. >>> >>> What do you think? >>> >>> Regards, >>> Anders >> Can we not get JacORB to fix that bug? >> >> BTW, should we release the maven plugin? > > Can't we just write one I like the spirit of that word "just". Nothing easier than writing an IDL compiler... :-) This is already tracked in YOKO-27. Should we start one in the svn sandbox (i.e. outside trunk) and see how it goes? In particular, it needs to attract a few developers, so please speak up if you're interested in contributing. > or maybe IONA could donate one? Their current position is they won't do that, see Adi's message on 31/5 in the "IDL to Java compiler" thread. > Alternatively, I think openorb has one, but IIRC it needs a lot of work. Forget it - it has a hand written parser and so many bugs that it's easier to write a new implementation from scratch. Regards, Lars
