[Biojava-dev] Plans for next biojava release - modularization

Richard Holland holland at eaglegenomics.com
Tue May 12 08:26:26 UTC 2009


The BJ3 code contains only as much code as is needed to represent
sequences and to parse/write simple FASTA. It should be viewed as a
concept. In particular the file parsing mechanism is quite flexible (if
a little complex) but easily wrapped with simple one-liner utility
methods to provide end-users with easier-to-use APIs.

Sequence representation in BJ3 is done via the Collections API. It's set
up in such a way that you can write something yourself that implements
the List API and behaves like a List but internally uses a more compact
or even offline storage mechanism to represent the sequence. This allows
you to reuse sequences wherever Lists can be used, e.g. in Iterators or
foreach-loops.

Everything written so far has been documented here:

  http://biojava.org/wiki/BioJava3:HowTo

cheers,
Richard



On Sun, 2009-05-10 at 21:26 -0700, Andreas Prlic wrote:
> Hi biojava-devs,
> 
> It is time to start working on the next biojava release.  I  would
> like to modularize the current code base and apply some of the ideas
> that have emerged around Richard's "biojava 3" code. In principle the
> idea is that all changes should be backwards compatible with the
> interfaces provided by the current biojava 1.7 release.  Backwards
> compatibility shall only be broken if the functionality is being
> replaced with something that works better, and gets documented
> accordingly. For the build functionality I would suggest to stick with
> what Richard's biojava 3 code base already is providing. Since we will
> try to be backwards compatible all code development should be part of
> the biojava-trunk and the first step will be to move the ant-build
> scripts to a maven build process. Following this procedure will allow
> to use e.g. the code refactoring tools provided by Eclipse, which
> should come in handy.
> 
> The modules I would like to see should provide self-contained
> functionality and cross dependencies should be restricted to a
> minimum. I would suggest to have the following modules:
> 
> biojava-core: Contains everything that can not easily be modularized
> or nobody volunteers to become a module maintainer.
> biojava-phylogeny: Scooter expressed some interested to provide such a
> module and become package maintainer for it.
> biojava-structure: Everything protein structure related. I would be
> package maintainer.
> biojava-blast: Blast parsing is a frequently requested functionality
> and it would be good to have this code self-contained. A package
> maintainer for this still will need to be nominated at a later stage.
> Any suggestions for other modules?
> 
> Let me know what you think about this.
> 
> Andreas
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
-- 
Richard Holland, BSc MBCS
Finance Director, Eagle Genomics Ltd
T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
http://www.eaglegenomics.com/





More information about the biojava-dev mailing list