Implement Graph Data Structures and Search Iterators#299
Conversation
The implementation SimpleGraph was undirected only. javadoc explanations for the methods have been added.
|
I'm ambivalent about including Graph code in BioJava. There are many packages for this already (e.g. jgrapht) that provide much more complete and feature rich implementations. On the other hand, I am reluctant to add another big dependency, even if just to the structure module. Are we OK with the status quo (SimpleGraph, buried in the symmetry package but slowly gaining additional features such as this pull)? Or should we at least make a separate package for it? |
|
Playing devil�s advocate, what is the aversion to �importing a whole external library� when that external library will have solved your problem already? Why re-invent this wheel? Later, Andy On 14 Jul 2015, at 16:51, Aleix Lafita notifications@github.com wrote:
The University of Edinburgh is a charitable body, registered in |
|
We recently added the vecmath dependency to the structure modules. Why not also add a dependency for a graph library? |
|
On 14 Jul 2015, at 17:13, Spencer Bliven notifications@github.com wrote:
If there is a genuine aversion to extra dependencies, make them �optional�. Then the end-user can include them explicitly if she/he needs them. Later, Andy The University of Edinburgh is a charitable body, registered in |
|
@andylaw The most straightforward way of executing a downstream tool requires listing all dependencies in the classpath. So adding a dependency means one more jar to ship with the tool, and one more -cp entry at the command line (yes, I am aware there are easier ways of distributing, but I believe that is still the recommended procedure). @andreasprlic Vecmath is different because it comes bundled with most JREs (either in java3d or as part of the core JRE) |
|
@andylaw Is there a clean way of making dependencies optional? Other than just omitting the jar and hoping you don't get a ClassNotFound at runtime? |
|
I believe that true in the dependency declaration in the pom file is the way to do it. Personally, I�d just slap the dependency in as a normal one in any case and leave those who are worried about their jar sizes to exclude it if it causes them problems. Later, Andy On 14 Jul 2015, at 17:27, Spencer Bliven notifications@github.com wrote:
The University of Edinburgh is a charitable body, registered in |
|
I have no problems with external dependencies as long as they are available from the Maven Central repository. For graphs I often use the Blueprints APIs so that the implementation is pluggable (e.g., in-memory, Neo4j, Titan). Such might be overkill for this specific use case though. |
|
I think it would be great to have some sort of Graph library for biojava, even if it is a basic one, since most problems are fundamentally graph searching problems. So from my ignorance on the dependency problems I vote to add a graph library. My idea was to put the most basic graph algorithms in the same place so that they can be reused, as simple as possible, since I was rewriting them in every method that needed a graph. |
|
I'd definitely support using an external graph library, personally I've used jgrapht a lot lately and I'm very happy with it. It can be used directly through maven central. Besides graph data structures and algorithms are likely to be needed elsewhere in BioJava sooner or later. Outsourcing things to an external library has only advantages in my view: clean, well-thought interfaces, well-tested and debugged code, more people contributing to it... Dependencies are easy to sort out with maven, that shouldn't be an issue. |
|
If jgrapht can easily replace the current implemention than I'm all for it. On Tue, Jul 14, 2015 at 11:09 AM, Jose Manuel Duarte <
Peter Rose, Ph.D. |
|
I close this because the decision was including a graph library as a dependency. I will keep the branch for some time just in case, and I will open an issue as a TODO for the graph library. |
7 participants
Since there was already a Graph interface and an implementation for Undirected Graphs in biojava (symmetry project) and I was using a lot graph searching algorithms and directed graphs for symmetry, I created some new classes to represent different types of Graphs and the two basic searching algorithms as iterators for them. New classes:
The idea is to have a set of basic and simple graph support, without importing a whole external library. The code is now in structure.symmetry.utils, would it make sense to create a new package for it? It is general enough so that it doesn't have to be inside the structure package.
Another possible extension for graph features would be to include Weighted Graphs, but I haven't done anything about that since I haven't need them until now.