On Sun, Feb 6, 2011 at 11:06 PM, Emmanuel Lecharny <email@example.com> wrote:
Just wondering : wouldn't it be a good idea to inject m1 into trunk now, and do the refactoring you are suggesting in M1 ?
On 2/6/11 9:54 PM, Alex Karasulu wrote:
I've finished the tasks with the first stage DIRSHARED-80 . 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.
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 improvements.