On Tue, Mar 8, 2011 at 10:09 AM, Pierre-Arnaud Marcelot <[email protected]>wrote:
> Hi Alex, > > That's something I had also noticed a few weeks ago. > See [1]. > > I wanted to decouple the SchemaObjects from the SchemaManager, but I guess > I ran into other work and couldn't complete it. > > AFAIR there are around 5 methods in the SchemaObject interface/abstract > class that needed to be removed and added in the SchemaManager utilities. > I'm not sure they are that much used outside of SchemaManager related > classes. > > On the lack of interfaces for schema objects, it's probably a little more > complex to move them back and requires more refactoring from depending > parts. > > Tell me if I can be of any help about those two matters. > > Regards, > Pierre-Arnaud > > [1] - http://directory.markmail.org/thread/mq2yerlo7b7dcd4m > > OK thanks Pierre for your assistance. I'm just trying to get my build back to normal now after merging in from trunks and confronting this maven-bundle-plugin issue discussed in the other thread. I want to clean up my build and then start analyzing a bit more, we can post ideas on the ML too but at the same time I want to experiment with some of the refactorings to see how it will look. Will keep everyone informed of my findings and thoughts. Thanks, Alex > On 8 mars 2011, at 00:09, Alex Karasulu wrote: > > Hi all, > > I just looked through the schema packages and noticed that it has > become another hives nest of inter-dependency. I'm not blaming anyone > here so please don't get the wrong idea. I just want to avoid these > trends because they cause more complexity and lead more unnecessary > work. Let me show y'all some code to be clear. > > There once were clean simple schema entity interfaces like > AttributeType that were used to shield the API from getting > contaminated by irrelevant implementation methods and functionality. > [0] shows an example of a clean interface which was there earlier that > most of the code handled. This was removed and replaced by a class. > Now look here [1] to see the big 1800 line file mixed with all sorts > of functionality [1] like addToRegistries(). This method has no place > in this object which is now used globally. As a result, > interdependencies have increased through and through inside these > packages as well as in the server which now depends on these out of > place methods. It's going to be a PITA to clean this up and the work > will be twice, maybe more, as hard as when the interfaces were > removed. The rest of the code base now has come to depend on these > non-essential methods specific to some function or use case associated > with implementation details. > > I'm trying to get some traction with making schema loadable and this > is yet another surprise to have to contend with. Please let's not > remove interfaces just because they seem unappealing. When in doubt, > leave the interface where it is, it can't hurt, but the opposite can > hurt a lot. I'm sitting here starring at this nest and wondering what > the heck I should do first. > > Best Regards, > Alex > > [0] - http://goo.gl/2j5dT > [1] - http://goo.gl/G7wBV > > >
