directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Shared] Refactoring update
Date Sun, 06 Feb 2011 21:42:47 GMT
On Sun, Feb 6, 2011 at 11:06 PM, Emmanuel Lecharny <>wrote:

> On 2/6/11 9:54 PM, Alex Karasulu wrote:
>> I've finished the tasks with the first stage DIRSHARED-80 [0]. Also on top
>> of this I decoupled the dsml-parser from all codec implementation classes.
>> Likewise for the ldap-client-api.
>> There are still probably some minor adjustments remaining.
>> Before merging this back into the trunk and going into the second stage
>> I'd
>> like to break apart the model now in one shot so we can continue working
>> on
>> it in the trunk. This might be good for you Pierre since you're working on
>> some refactoring right now in model.schema. Even if I do this now though I
>> highly recommend working together on the m1 branch together while we break
>> things up further.
>> It makes more sense to break up the modules right now instead of later.
>> Then
>> the paths and project layout is set making merges into m1 from trunk much
>> easier to handle and vice-versa.
>> If there are no objections I'm going to handle this tonight. The new
>> ldap-model OSGi module and perhaps others will impact the build
>> descriptors
>> for studio. I'll try to get those working as well but if I cannot by
>> tonight
>> I might ask for a hand tomorrow.
>> Any questions?
> Just wondering : wouldn't it be a good idea to inject m1 into trunk now,
> and do the refactoring you are suggesting in M1 ?
Just saw this now. I started the process but can revert. Actually it would
be better for us this way because when PAM works on the schema, the classes
will not move down the line. We'll be at least in sync WRT file names and
paths which helps a lot on merges.

> The idea would be to have at least a stabilized version in trunk in case if
> the refactoring takes to much time.

Actually all the refactoring was already done the weeks before. I just need
to split the module off and did it. It works like a champ. I'm now going to
update eclipse descriptors for studio to include the new model bundle.

> Also m1 as it is now is much better than trunk, so I think that having it
> in trunk is beneficial until we get the refactored version ready.
All I did is create a new module. I can do it again if need be no big deal.
I was simply thinking it's better for us to have common paths on the model
before Pierre went to town on his schema refactoring tomorrow.

> Btw, tomorrow I'm coming back from germany, and will be in the train fro 7
> hours, with no connection.


> I started to changes sme things in the LdapGrammar class, namely extracting
> all the actions in dedicated classes, to make the class shorter (it's more
> than 7000 lines, to big to be handled).

Yes this file is extremely cumbersome. Will be nice to have it broken up.

> I will probably continue this work in the train : it has no impact on the
> tests, and does  not ovelap with the existing work going on.
Yup you should be perfectly fine since it's codec isolated. This is one of
the advantages we're now going to have. Because the implementation is
isolated and hidden, it's not going to impact our users while they'll see
better organization in the implementation, perhaps bug fixes and performance


View raw message