[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