directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: [Apache DS] Shall we go JDK 1.5 in 1.1 branch
Date Mon, 13 Mar 2006 05:35:50 GMT

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 .  
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 .



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?

View raw message