directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Shared refactoring : what's going on, some feedback
Date Sun, 23 Jan 2011 15:34:12 GMT
Thanks Emmanuel for the status update.

I must admit that I'm a bit lost in following all the modifications.
But I trust you all that you do the right things. It's good to see
progress.

Kind Regards,
Stefan


On Sun, Jan 23, 2011 at 11:06 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> Hi guys,
>
> as you noticed, some heavy code refactoring is going on in shared. Let me
> give you some feedback about what is being done, and the reasons for those
> refactoring.
>
> First of all, the idea is to release a shared/LdapAPI 1.0-M1 asap. It will
> be LdapAPI from this point, and not anymore shared. This will be a
> milestone, but it will also be a first step toward the exposed API. When we
> will come with a 1.0-RC1, the API will have to be frozen. That being said,
> let's see where we are going to :
>
> - base class renaming. You can see that Alex changed DN to Dn, etc. The
> rational behind those renamings is that it's consistent with the name scheme
> we use : caml humps all over the code. We have a DnParser class, and a DN
> class, which is not consistent. All in all, we discussed those names back in
> september, and if you really feel that DN is better than Dn, we can revert,
> but I thik it's not really a technical issue, much more a choice to make. To
> me, it's not an issue at all.
>
> - API/SPI separation : most of what Alex is doing right now is about hiding
> implementation from the exposed API. The less classes exposed, the less
> problem we might have with users using the SPI classes. ALso consider that
> the API documentation will be more tight.
>
> - OSGi : shared has been completely OSGified, and it's a good thing. We have
> postponed this task year after year, but we reached a point it was to be
> done. One of the reason was that refactoring shared without impacting Studio
> was impossible, because Eclipse dos not allow a project to 'see' shared as a
> dependent source project, so we had to propagate the changes manually,
> something we don't want to do anymore. With the OSGi bundles, studio is now
> directly impacted by shared refactoring without any need to do it by hand.
> Plus OSGi is the best way to manage dependencies, and for shared, it cost
> almost nothing to switch to OSGi (well, it took one day). I also do think
> that after shared refactoring, we have to go for Apacheds.
>
> At the end of the day, the refactoring should be finished soon (maybe one or
> two more days). It may create new sub-modules, which may be gathered later,
> not a big deal. Just keep an eye at what is being done, if you disagree,
> feel free to express your opinion.
>
> One important point is that we are using a c-t-r mode (commit then review)
> and not a r-t-c, and I think we don't want to switch to a r-t-c at this
> point of the project :). Committing is not for ever, you can -1 one commit,
> it's not an insult to the one who did the commit. I repeat, -1 a commit is
> not an insult. Just be rational, and express your technical vision when you
> -1 something.
>
> All in all, at first I was quite conservative, but I realized that we
> probably need some fresh perspective, because we are all so deeply involved
> that we don't have anymore a 10K feet vision necessary to see what's wrong
> and what's good. It's a good timing now that the API is stable to review it,
> shake it and make it better.
>
> Guys, I engage you to look at what Alex is doing when it will be done, and
> express your opinion then. I think this is one unique opportunity to move
> away from a local minimum to the next stable state.
>
> Thanks !
>
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>

Mime
View raw message