dependencies, methods and building graphs

[eparejatobes]

Discussing this with @evdokim

• at the abstract level, split everything into subprojects, with "linking" modules refining the corresponding types. Methods throw exceptions describing the missing module/s
• for implementations, the node has fields for all possible graphs that it might need, and it extends all the possible abstract extensions. It has a constructor with all these fields, and you can build it step by step with with builder methods. At the implementation site, you check for nulls (and throw the corresponding exception if needed)
• Actually, you only need to put all those graph fields in the graph. The nodes and rels can get them through te corresponding fromXXX methods in their node/rel types.

[eparejatobes]

@pablopareja an update on this. This issue about multiple graphs and dependencies is kind of complex from a generic perspective, and there's no completely satisfying solution for it. It is related though with defining all the in, out methods in typed-graphs at an abstract level: Node and not just TitanNode. As the top priority right now is to get this working, we are doing things essentially as you have them in #22. The only detail is that you should declare the possible extensions of a module as methods in the corresponding graph; see my last commit in #22.

In summary

• we just add methods to the graphs returning the possible extensions to that module
• in the future this will be cleaner, I just need a couple of days to refactor some stuff in typed-graphs; this will let us have most of the data access methods already implemented at the bio4j/bio4j level.

[eparejatobes]

this and much more has been done, we are so cool