Alex, Cross posting to dev@geronimo... since Geronimo has been mentioned a few times in this thread. AFAIK the statement below that Geronimo's latest development branch will use JDK 1.5 does not reflect past discussions on the dev@geronimo thread http://thread.gmane.org/gmane.comp.java.geronimo.devel/22157 . Where JEE 5 support will be developed is yet to be decided. Can you confirm that you are proposing that both Apache DS 1.0, 1.1 & 1.2 will be embeddable in Geronimo on JDK 1.4.2 . Thanks, John Alex Karasulu wrote: > I was going to write a long email about this but let me condense it. > (1) JDK 1.4 and up is supported for all user types (including > embedding users) in 1.0 branch and this will never change. This > branch is alive and well and will be maintained with bug fixes. There > already are features in this branch that are 1.5 specific and you can > get those by adding some extra "components" but must run them on JDK > 1.5 (SSL is the only JDK 1.5 requirement at this point). > > (2) The 1.1 branch is an experimental/feature addition branch. Even > Geronimo will not look back and will use JDK 1.5 for there latest > development branch. Does this mean we have to? Not necessarily. > This branch will most likely add compliance with OpenGroup. It will > also introduce enhancements for performance in the database, DN > handling and in the asn1 subsystems. This branch will release often > hopefully but that does not mean users should use it. The real > culmination of this branch will be the stable release of 1.2. This > will take 4-6 months at a minimum. In that time more users will be on > JDK 1.5 but we will still have most users on 1.4. > > (3) A clean break is always better than a half assed job period. > However we need to get our timing straight. That's all this JDK > discussion is really about. So we have to pick just when we make this > jump. > > So now here's my opinion: > > (a) MINA sticks to 1.4 support without messing with byte code and > experiments with retroweaver. She should release a 1.0 and have a > solid stable API for 1.4 and 1.5 support. At this point I'd like to > see mina graduate incubation and start a new branch 1.1 which focuses > on JDK1.5 with mina 1.0 as 1.4 fall back. This can occur in about 4-6 > months IMHO. > > (b) ApacheDS sticks to 1.4 support in the 1.1 and 1.2 branches. For > 1.5 needs it juggles new components and leverages OSGi to help manage > this. SASL, SSL, Crypto libs and other features that may need 1.5 can > load 1.5 specific bundles to do this. This sucks and is going to be a > pita for us the developers but we can do it and we have OSGi to help. > At this point 1.0 dies and 1.2 becomes the main supported branch. > (c) Once MINA graduates and starts work on a pure JDK 1.5+ branch we > can start a new experimental branch for ApacheDS, branch 1.5 skipping > 1.3 altogether. Here we redesign the server to use all 1.5 features. > The design/architecture and readability, maintainability greatly > improves. We then bump up the GA release branch to 2.0. This is a > year out in the making. Plus it will coincide with mina 1.1 or > whatever we choose it to be designated as for jdk 1.5 support. At > this point we can decide to kill 1.2 or to keep on supporting bug > fixes in it for 6 more months (recommended) until SUN puts an EOL on > jdk 1.4. > > > Summary > ======= > > (1) Users are happy, embedding and standalone users > (2) Developers deal with the burden but use OSGi to alleviate the pain > (3) We have a clean manageable break which will make life bearable > (4) MINA progresses forward with 1.0 and 1.1 jdk 5 support with a nice > clean break and gets a new home as it should > (5) ApacheDS 1.2 will pretty much have the same functionality as 2.0 > so there will be little complains. The server will just be redesigned > to make it easier for developers. There is only so much you can do > with LDAP, DNS and Kerberos. > > DHCP is another story but we can talk later about this one. > > Heh we can deal later with these headaches 1.6 will bring a year from > now. > > Cheers, > Alex > > P.S. Can we agree on this and forge ahead please? > > >