IMO doing as little as possible to while doing the conversion is best. I would keep unused classes where they are until the conversion is complete. And then we can review what needs to be removed when the dust settles. Who knows what other problems will arise. Phase 3 is more like a cleanup phase where we evaluate the impact of these changes and do some house keeping.
Also shared-ldap is huge because many things were put in there from the core. Now we want to move it back. I don't want to keep oscillating but would prefer to make final moves that progress us to a better state. Who knows a bunch of code may need to just be removed and or pushed to some other shared-ldap-old module that eventually can be deleted. However we just don't know if this should be deleted either since it might need to go into the jndi-wrapper module that we're going to build after removing all this JNDI code from the core.
I'm just uncertain and when uncertain it's always best to just chill with big changes that are not relevant to the prime directive at hand. I want to consider what you're talking about but let's do it when our world is busy dealing with all these massive refactorings.
I' still changing every occurence of [Basic]Attribute[s][impl] we have
in the server, and I'm now facing some interesting challenges :
shared-ldap contains a lot of helper classes and methods which were
created to help the poor souls when they were manipulating the JNDI
objects. Those helper methods/classes are not anymore necessary, or if
they are, they do not deserve to be included into shared-ldap, I think.
What if we move those elements into core-entry ? The main reason is that
we need to access server specific elements, which are not available in
shared-ldap ( for evident cycle dependency avoidence reasons).