Re: shared-ldap merge done
On 9/21/10 12:20 AM, Alex Karasulu wrote: On Tue, Sep 21, 2010 at 12:48 AM, Emmanuel Lécharnywrote: We are talking about the release of shared, not the server, here. I'm fully aware of that. I just mentionned this because in one of my previous mail, I talked about waiting for a release of ADS 2.0-RC1, which seems a bit too far... I was also thinking about the general layout of packages/classes etc, and we may have to careful review them before releasing the final 1.0 version, because then we are dead for years ! If we were going to merge and rearrange it might be a good time to review packages for the sake of turning modules into OSGi bundles in shared. Absolutely. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: shared-ldap merge done
On Tue, Sep 21, 2010 at 12:48 AM, Emmanuel Lécharny wrote: > On 9/20/10 11:21 PM, Alex Karasulu wrote: > >> On Sun, Sep 19, 2010 at 2:38 AM, Emmanuel Lecharny> >wrote: >> >>> That's all what I had in mind when I asked Alex to do that in a branch : >>> I >>> >>> was scared that it can break the schedule we are trying to set :/ >>> >>> May be I'm wrong, or just extra cautious, I don't know... >>> >>> >>> Let's play it safe and get the release out without worrying about this >> additional factor. >> > We are talking about the release of shared, not the server, here. > > I'm fully aware of that. > I was also thinking about the general layout of packages/classes etc, and > we may have to careful review them before releasing the final 1.0 version, > because then we are dead for years ! > > If we were going to merge and rearrange it might be a good time to review packages for the sake of turning modules into OSGi bundles in shared. > IMO, the very first step (once we have fixed the last few pb we have with > the GSSAPI) would be to release shared-0.9.20 > > +1 -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: shared-ldap merge done
On 9/20/10 11:21 PM, Alex Karasulu wrote: On Sun, Sep 19, 2010 at 2:38 AM, Emmanuel Lecharnywrote: That's all what I had in mind when I asked Alex to do that in a branch : I was scared that it can break the schedule we are trying to set :/ May be I'm wrong, or just extra cautious, I don't know... Let's play it safe and get the release out without worrying about this additional factor. We are talking about the release of shared, not the server, here. I was also thinking about the general layout of packages/classes etc, and we may have to careful review them before releasing the final 1.0 version, because then we are dead for years ! IMO, the very first step (once we have fixed the last few pb we have with the GSSAPI) would be to release shared-0.9.20 Then we will have a few time to get all of it reviewed (I have started that 2 weeks ago, cleaning up around 80 files out of 800) and eventually adding OSGi stuff around it. At this point, shared is now 7 modules, and I really don't see why we should keep shared-ldap-jndi and shared-ldap-schema separate. If we have a look at shared-ldap, then it's immediate that we may have to move out some packages and rename some others : - o.a.d.s.ldap.shared.converter.schema should be more likely o.a.d.s.ldap.shared.schema.converter - o.a.d.s.ldap.shared.csn should be in another package with entry, subtree, sp, aci, filter and cursor : they are LDAP internal objects, distinct from messages, ldif or schema. May be something like o.a.d.s.ldap.shared.objects ? - o.a.d.s.ldap.shared.name could also be part of the previous package (o.a.d.s.ldap.shared.objects) In other words, I *know* for sure we have to reorganize those guys, and I really think we should release before starting moving around those guys more, or adding more features in it. We can define a schedule for that we can all agreed on, and get it done quickly, don't you think so ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: shared-ldap merge done
On Sun, Sep 19, 2010 at 2:38 AM, Emmanuel Lecharny wrote: > On 9/18/10 9:20 PM, Stefan Seelmann wrote: > >> >> One more thing, just to clarify my last mail about OSGi (I read it and >>> found >>> it a bit like I was micro-managing) : I think that we should wait for the >>> next release of ADS (ie, post 2.0.0-RC1) because we will probably do some >>> other changes in shared (like rename it to API) and we would like to >>> release >>> this asap. Working in a branch on OSGi is just a way to be sure that >>> there >>> won't be any contention in this area, and of course, if the OSGi >>> implementation is finished before we are ready for a release, I have >>> nothing >>> against merging back the branch into trunk. >>> >> Is it really that difficult to make shared/api OSGi bundles? Please >> correct me if I' wrong, but we just need to add the right >> META-INF/MANIFEST.MF that could be generated by the Felix plugin. >> Additionally we need to make sure that we have now split packages, >> that is atm the case for o.a.d.shared.ldap.schema, but could be fixed >> easy. My hope is that we can then use the shared/api bundle directly >> in Studio. >> > > I have no idea. I just want to be sure that it does not stop us when we are > so close to a release. We may aven do that after we have released Shared/API > and before ApacheDS 2.0-RC1. I mean, we have almost closed all the issues we > have in API and shared expecting to be able to release this week, and now > that it's done, thinking about adding these OSGi stuff is just a bit too > much for me. More or less, it's just a problem in the agenda, not a > technical issue. > > I agree with Emm here it's not worth the hassle unless you guys see it as a clear benefit in Studio. > In other word,s if this take 2 hours, and not 3 days, I'm +1, but what I'm > afraid of is that we don't have enough people with some knowledge in this > area to solve an issue that would potentially arise just before, or even > worse, just after we have released. > > Yes this is a worry of mine as well but I was thinking this was a small effort for shared and much much more complicated for the server itself. > That's all what I had in mind when I asked Alex to do that in a branch : I > was scared that it can break the schedule we are trying to set :/ > > May be I'm wrong, or just extra cautious, I don't know... > > Let's play it safe and get the release out without worrying about this additional factor. Regards, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: shared-ldap merge done
On Sat, Sep 18, 2010 at 10:20 PM, Stefan Seelmann wrote: > On Sat, Sep 18, 2010 at 7:09 PM, Emmanuel Lecharny > wrote: > > I have successfully merged many modules in shared. The remaining modules > are > > : > > - ldap-client-api > > - shared-all > > - shared-dsml-parser > > - shared-i18n > > - shared-ldap > > - shared-ldap-jndi > > - shared-ldap-schema > > Thanks Emmanuel! > > > There are a few more things we could do here : > > - ldap-client-api should also be merged in shared-ldap > > - shared-ldap-schema is a separate module, but I think it could also be > > injected into shared-ldap > > - shared-i18n is a separate module for convenience reason : it would have > > been painful to work on translation in another module. > > Ok > > > We can discuss further about what should be done in this area, I don't > want > > to go too far and have to rollback. > > > > The next big step will be the shared/api renaming, something I'd like to > do > > either this week-end or at the very beginning of next week. Then we will > > probably be ready for a API/shared release. > > > > One more thing, just to clarify my last mail about OSGi (I read it and > found > > it a bit like I was micro-managing) : I think that we should wait for the > > next release of ADS (ie, post 2.0.0-RC1) because we will probably do some > > other changes in shared (like rename it to API) and we would like to > release > > this asap. Working in a branch on OSGi is just a way to be sure that > there > > won't be any contention in this area, and of course, if the OSGi > > implementation is finished before we are ready for a release, I have > nothing > > against merging back the branch into trunk. > > Is it really that difficult to make shared/api OSGi bundles? Please > correct me if I' wrong, but we just need to add the right > META-INF/MANIFEST.MF that could be generated by the Felix plugin. > Additionally we need to make sure that we have now split packages, > that is atm the case for o.a.d.shared.ldap.schema, but could be fixed > easy. My hope is that we can then use the shared/api bundle directly > in Studio. > > Exactly it's not so much the manifest generation which is really easy with the Maven OSGi Plugin using BND. The problem really is making sure we have split packages. I wanted to sit down and review the current breakdown of our classes, interfaces and packages to see if we had the proper package/class/interface layout. The only part that I was worried about is getting all the exported classes right so the API will function properly. I also thought this would be great for Studio as well cuz then the API jar is a bundle on it's own rather than being embedded into another bundle. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: shared-ldap merge done
On 9/18/10 9:20 PM, Stefan Seelmann wrote: One more thing, just to clarify my last mail about OSGi (I read it and found it a bit like I was micro-managing) : I think that we should wait for the next release of ADS (ie, post 2.0.0-RC1) because we will probably do some other changes in shared (like rename it to API) and we would like to release this asap. Working in a branch on OSGi is just a way to be sure that there won't be any contention in this area, and of course, if the OSGi implementation is finished before we are ready for a release, I have nothing against merging back the branch into trunk. Is it really that difficult to make shared/api OSGi bundles? Please correct me if I' wrong, but we just need to add the right META-INF/MANIFEST.MF that could be generated by the Felix plugin. Additionally we need to make sure that we have now split packages, that is atm the case for o.a.d.shared.ldap.schema, but could be fixed easy. My hope is that we can then use the shared/api bundle directly in Studio. I have no idea. I just want to be sure that it does not stop us when we are so close to a release. We may aven do that after we have released Shared/API and before ApacheDS 2.0-RC1. I mean, we have almost closed all the issues we have in API and shared expecting to be able to release this week, and now that it's done, thinking about adding these OSGi stuff is just a bit too much for me. More or less, it's just a problem in the agenda, not a technical issue. In other word,s if this take 2 hours, and not 3 days, I'm +1, but what I'm afraid of is that we don't have enough people with some knowledge in this area to solve an issue that would potentially arise just before, or even worse, just after we have released. That's all what I had in mind when I asked Alex to do that in a branch : I was scared that it can break the schedule we are trying to set :/ May be I'm wrong, or just extra cautious, I don't know... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: shared-ldap merge done
On Sat, Sep 18, 2010 at 7:09 PM, Emmanuel Lecharny wrote: > I have successfully merged many modules in shared. The remaining modules are > : > - ldap-client-api > - shared-all > - shared-dsml-parser > - shared-i18n > - shared-ldap > - shared-ldap-jndi > - shared-ldap-schema Thanks Emmanuel! > There are a few more things we could do here : > - ldap-client-api should also be merged in shared-ldap > - shared-ldap-schema is a separate module, but I think it could also be > injected into shared-ldap > - shared-i18n is a separate module for convenience reason : it would have > been painful to work on translation in another module. Ok > We can discuss further about what should be done in this area, I don't want > to go too far and have to rollback. > > The next big step will be the shared/api renaming, something I'd like to do > either this week-end or at the very beginning of next week. Then we will > probably be ready for a API/shared release. > > One more thing, just to clarify my last mail about OSGi (I read it and found > it a bit like I was micro-managing) : I think that we should wait for the > next release of ADS (ie, post 2.0.0-RC1) because we will probably do some > other changes in shared (like rename it to API) and we would like to release > this asap. Working in a branch on OSGi is just a way to be sure that there > won't be any contention in this area, and of course, if the OSGi > implementation is finished before we are ready for a release, I have nothing > against merging back the branch into trunk. Is it really that difficult to make shared/api OSGi bundles? Please correct me if I' wrong, but we just need to add the right META-INF/MANIFEST.MF that could be generated by the Felix plugin. Additionally we need to make sure that we have now split packages, that is atm the case for o.a.d.shared.ldap.schema, but could be fixed easy. My hope is that we can then use the shared/api bundle directly in Studio. Kind Regards, Stefan
shared-ldap merge done
Hi guys, I have successfully merged many modules in shared. The remaining modules are : - ldap-client-api - shared-all - shared-dsml-parser - shared-i18n - shared-ldap - shared-ldap-jndi - shared-ldap-schema There are a few more things we could do here : - ldap-client-api should also be merged in shared-ldap - shared-ldap-schema is a separate module, but I think it could also be injected into shared-ldap - shared-i18n is a separate module for convenience reason : it would have been painful to work on translation in another module. We can discuss further about what should be done in this area, I don't want to go too far and have to rollback. The next big step will be the shared/api renaming, something I'd like to do either this week-end or at the very beginning of next week. Then we will probably be ready for a API/shared release. One more thing, just to clarify my last mail about OSGi (I read it and found it a bit like I was micro-managing) : I think that we should wait for the next release of ADS (ie, post 2.0.0-RC1) because we will probably do some other changes in shared (like rename it to API) and we would like to release this asap. Working in a branch on OSGi is just a way to be sure that there won't be any contention in this area, and of course, if the OSGi implementation is finished before we are ready for a release, I have nothing against merging back the branch into trunk. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
