Darren Middleman wrote:
Hi Alan,
You are right about the checked in generated code. We checked in the
generated code as we didn't have a suitable IDL compiler to generate the
source during the Yoko build. I seem to recall there being some
issues with
using the IDLJ compiler that comes packages with the JDK, so that
wasn't an
option.
As for the missing IDL, as long as the generated code came from a CORBA
defined IDL file, then the IDL will be available from the OMG. I can't
recall at the moment if there was any code that might have been generated
from any proprietary IDL, which might be what was meant by the IDL
being no
longer available.
There are still bits of the org.omg.* classes that are getting generated
at build time from the idl. However, I believe Alan was referring to
the core bits of the ORB code that appear to have been once generated
from IDL, but are no longer. These classes follow the IDL generated
conventions of having operations classes, helpers, holders, etc., even
though these classes are only used internally within the ORB and are
never accessed as CORBA objects. The org.apache.yoko.orb.OB package has
a lot of these, for example. The code is there, and follows the
conventions used with idl-generated classes. The original IDL is no
longer available, which makes enhancing some of these classes a
royal pain to deal with.
Rick
Darren
On 7/26/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
A while back Lars asked this question:
Some classes seem to be generated from IDL. Why is it necessary to
retain the Xyz/XyzOperations hierarchy when the sources are now
managed in svn and the original IDL is no longer available?
I'm confused. If the classes are generated from IDL then how can the
original IDL be no longer available?
I hold a strong aversion to checking in generated code. IMO, code
generated from IDL should always be generated from IDL. However, at
the moment, we're without an IDL compiler so I think that is why we
check in the generated code into svn.
Regards,
Alan
