[Biojava-dev] next steps

Andreas Prlic andreas at sdsc.edu
Mon May 25 15:14:06 UTC 2009


> 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.

yea, same for Eclipse. The Eclipse Maven plugin allows to auto-convert
a project to Maven (quite easy).  I have played around with it and it
was quite easy to get a mavenized biojava with the dependencies
correctly converted.  That's why I thought it might be the first step.
You suggest to first do the modularization and then the maven meta
data.  I still have to figure out how to make make independent
submodules as part of Maven in eclipse now.... let me play around a
bit more and see how it goes...

The package list sounds good and java 1.6 too.

Andreas


>
> 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
>




More information about the biojava-dev mailing list