directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Shared refactoring : what's going on, some feedback
Date Mon, 24 Jan 2011 12:29:08 GMT
Hi guys,

On 23 janv. 2011, at 11:06, Emmanuel Lecharny 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.

Not an issue, but I wish we had discussed that rollback before on IRC since we had all agreed
to stick this particular naming some time ago on the API ML.


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

Very important and mandatory.
+1!


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

I couldn't be happier since it will make the Studio build a lot easier (after we manage to
stabilize the whole thing). :)

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

I fixed a few issues here and there related to Studio and Shared dependencies. There's still
a small issue when using Studio in Eclipse (ClassNotFoundException) but this it going to be
fixed soon.

Thanks,
Pierre-Arnaud
Mime
View raw message