[Biojava-dev] next steps

[Scooter Willis]

Andreas
 
I was looking at the biojava code yesterday to see how easy it would be to divide up into functionally grouped jars based on package hierarchy. I tried to find some refactoring tools that would give a network graph view of class relationships. It is simple enough to parse source for import statements and build some sort of graph relationship tool. It is also easy enough to start dragging packages around to different projects in netbeans and resolve compiler errors.
 
The advantage of smaller tightly group functional jars is that it allows you to have more frequent minor releases with out updating and releasing the entire biojava package. It also allows individuals to own a smaller block of code for unit test, documentation and examples. 
 
With Maven this becomes less of an issue to worry about multiple parts and pieces and their relationships. I think we need to divide up into a reasonable approximation of the jars before doing the meta data for maven. 
 
Looking at the current package structure this is an attempt of grouping jars. I do not have enough code familiarity with all of biojava so this is strictly based on package names.
 
biojava-core Any classes that organize data structures and would probably include org.biojava.bio.seq.*. Any utility classes that can be used by other packages org.biojava.utils.*
 
biojava-structure org.biojava.bio.structure.*
 
biojava-gui org.biojava.bio.gui
 
biojava-phylo A package that has a few classes for viewing trees structures using the jgrapht-jdk package. I need to play with the code and see if it actually uses graph generated by jgrapht for anything special. I have code that will render a tree as a simple graphic. I have used jgrapht for other projects so it is not a bad "graphing" package for network diagrams. It could be refactored out.
 
Not sure how to tackle the org.biojava.bio.program package as it seems to have lots of distinct functional code.
 
biojava-ws-blast - A web service approach to doing blast. The api would hide the web services call 
 
biojava-blast - Blast parsing code. We could have one package for anything blast related
 
biojava-ws-clustalw - A web services approach to doing clustalw multiple sequence alignment The api would hide the web services call 
 
biojava-alignment - Code for doing sequence alignment. We could have one package for anything alignment related
 
Does anyone know if you can get usage statistics from maven as to what jar files are being downloaded? This would help provide good statistics on what code is being used which will help focus on improvements in documentation etc.
 
I assume we are going to make Java 1.6 the minimum requirement moving forward? This simplifies some of the web services api requirements to minimize the number of external packages that are required. 
 
 

Scooter
 
 
 
 
 
 
 

________________________________

From: biojava-dev-bounces at lists.open-bio.org on behalf of Andreas Prlic
Sent: Mon 5/25/2009 12:22 AM
To: biojava-dev at lists.open-bio.org
Subject: [Biojava-dev] next steps



Hi,

While talking about design requirements, I think we also need to think
pragmatically about how much time we will have to refactor code vs.
re-writing modules from scratch. To get started with the next steps, I
 suggest the following procedure: First thing will be to move to
Maven. Then components should be refactored into independent
sub-modules. Then the submodules can get improved to follow the new
design guidelines. Once we have reached a certain stability with the
re-organized code base, we will make the next release.

Any comments? If there is general agreement about this, I would take
the next step and replace the ant build system with a maven based one.

Andreas
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev