Lars Kühne wrote:
Alan D. Cabrera wrote:
I want to extend an invitation out to all the OpenORB developers who
might be interested in helping out. Lots of great work out here!
I'm one of them, but I don't use Geronimo and I haven't looked at G's
architecture.
Some of these points have already been made in this thread:
1. The code really should be in cvs/svn so it's easy to send in patches.
2. The code needs to be buildable, and preferably have tests, so it's
easy to try out changes.
3. A high level description of the core code and the module structure
above core would be great. It seems that the directory layout is
designed to host other modules as well. What would these other
modules be? Top level components like an IDL compiler and a
NamingService implemenation? That would be cool, because I'm
currently working on a Apache licensed IDL compiler.
Once #1 is in place, I think I can start working on #2, although I can't
promise more than maybe a few hours per week, and the ORB kernel is not
my primary area of expertise within OpenORB.
There certainly is demand for a complete Apache licensed ORB
implementation outside Geronimo. Personally I would need that to replace
OpenORB in our code (we use plain CORBA, without a container), but other
projects like Apache Harmony would benfit as well. This means that there
should be no dependency from the ORB core to Geronimo.
Is support for Java 1.4 a requirement in Geronimo, and if yes then for
how long? In Java 5 many infrastructure classes like j.u.concurrent and
JMX are available without introducing any external dependencies, and
support for SSL seems to be much better (no personal experience). Would
it be OK for the ORB to require Java 5?
I think we should be supporting 1.4.2 (and 1.5) for a while, as many
large enterprise systems are slow (like a year or two behind) to move to
recent (1.5) versions of Java, for many reasons.
Could relying upon external dependencies be a positive.. e.g. a more
supportable/patchable system, rather than having to wait for a fix in a
later JDK release?
Eventually we should drop support for 1.4.2, but hopefully not for a while.
How do others feel about this?
John
Last but not least I'd like to thank Trifork for starting this
initiative and donating their code.
Regards,
Lars
