On Tue, Mar 8, 2011 at 10:09 AM, Pierre-Arnaud Marcelot <pa@marcelot.net> 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