Hi everyone,
I have to say, I love this plan. I really like the simplicity of it,
and it addresses one of the worries I had. I was extremely concerned
that we would have problems integrating OpenEJB 1 features and
architecture into the OpenEJB 2 tree while keeping it stable for
Geronimo. I believe that when you make a major architectural change
you need a new major version number. In this case, I am sure that
combining OpenEJB 1 and OpenEJB 2 will require a new hybrid
architecture.
One issue I am concerned about in this plan is the idea of attaching
and EJB 3 implementation to OpenEJB 3. I think this is a great goal,
but I don't want to see it holding up an OpenEJB 3 release. I think
that the spec will take a long time to get out and an implementation
may take a long time. If we can pull it off, that would be great,
but if we only have a "preview" by the time OpenEJB 3 is ready, I
think we should ship anyway.
Again, excellent plan and remember 1+2=3,
-dain
On Jun 15, 2005, at 4:50 PM, David Blevins wrote:
This message goes out to all the users and developers and is a direct
request for comments. Please give us direction.
STATUS
So here is where we are it in the project.
- We have the 1.0 code which is pretty much the same as 0.9.2 with
the addition of a Web Administration Console, EJB 2.0 Local
Interface support, and an addition form of OpenEJB/Tomcat
integration scoped at just the webapp level.
- We have the 2.0 code which is pretty much tied to Geronimo and has
none of the features that existing OpenEJB users have come to
expect: easy unit testing of ejbs; any form of tomcat integration;
easy config files; tools to validate ejbs. It does have ejb 2.1
functionality (webserivces, cmp2, mdbs).
I've been very hesitant to release anything from the OpenEJB 2.0 tree
as it is just going to work in the same way that OpenEJB 1 (0.9.2)
does. The trick is also that all the resources on the project have
focused solely on implementing 2.1 so we never seem to get to 1.0
either.
GOALS
I think top priority is getting OpenEJB back in the hands of OpenEJB
users. At this point I don't think this means giving you all a 1.0,
you deserve the EJB 2.1 functionality you were promised and the great
things you like about 0.9.2. Further, unless we get a jump on
starting an EJB 3 implementation focused on existing OpenEJB users,
we'll be in the same position we were in on the EJB 2.1 code.
DIRECTION
Here is where we need your feedback. This project exists for you
guys, so we need to here from as many people as possible. The
more the better.
What if we just put out the 1.0 "as is" did minor bug fixes on it, but
nothing major in terms of features. Admitted the 2.0 code is pretty
much Geronimo's and just left it alone for the most part. And...
we start on OpenEJB 3 by taking the 1.0 (pretty much the same as
0.9.2), merging in parts of the 2.0 code, and (here is the important
part) ensuring that the entire time the code we write is code you can
use! We will never drop a feature, even temporarily. This is also
where we would develop EJB 3 compliance. We will start from code that
users are now using and always keep, maintain, and improve those
features as we add new features. Releasing early and often.
How does that sound?
Here is how I am imagining we could do that technically:
1. Take the OpenEJB 1.0 code and kill all the ugly static code and
make it IoC with the gbean.org kernel. The gbean kernel is an
IoC kernel compatible with both Spring and Geronimo. So people
using OpenEJB could leverage (and write) both Spring components
and Geronimo components. See http://gbean.org
This would entail no change to OpenEJB as you know it, but would
allow you to start experimenting with Spring on apps already
working with OpenEJB 0.9.2.
2. As the gbean.org stuff is both Spring and Geronimo compatible,
it provides a great way for us to take the Geronimo-compatible
EJB containers and deployers in OpenEJB 2 and start hammering
them out and releasing them to you.
3. All EJB 3 work would be done as components and made available to
you in various forms of stability as things go along, meanwhile
that won't slow down the entire OpenEJB 3 set of code.
The effect of all this is that you get a fixed-up, far more
extensible, version of the code you are already using delivered to you
right away. We can basically start releasing 1.0 as 3.0 now and keep
releasing as we execute on step 1. As step 1 gets further along, we
can start in on step 2, and still keep releasing. At any point after
step 1, we can open things up for people to come in and work on EJB 3.
Again, the overall goal is to start with code you are using now and
ensure that when we take a step forward, we aren't leaving you behind
by removing things you depend on (tomcat integration, testability,
embeddibility, ease of use, etc).
FEEDBACK
So here is where we need as many people as possible to shout out and
say "yes" or "no" or anything else you want to add.
Is this where you want the project to go? <<<<
Feedback from you is critical.
Best regards,
David Blevins
