[Biojava-dev] BioJava 3 code usage examples

[Richard Holland]

Hello. Thanks for spending the time looking into the code. It's a bit
like a virtual code review session for me... you've made some very
useful comments.

> 1) It doesn't seem that you want to avoid name conflicts with the old
> version because you are continuing using the package name "org.biojava.*"
> instead of "org.biojava3.*"

Yes, I agree, I think they should be changed to org.biojava3. I will
do this when I get 5 minutes spare. They should be in org.biojava3
because one of the stated goals was to be able to write a
biojava-biojava3 mapper module if someone needed that to happen, and
the use of org.biojava in the new code would preclude that.

> 2) The old biojava version arranges sequence related classes in a
> hierarchical fashion, while in the new version you put the FASTA parsing
> classes directly under a first level node "org.biojava.fasta" rather than
> under the "org.biojava.seq" as before. There are tens of popular file
> formats in the bioinformatics world, so will all of them crowd the first
> level nodes under the root package?

That's also a good suggestion. I'll move it. It makes no difference to
the physical structure of the project on disk, but it would make class
and package browsing easier to do, especially in JavaDocs.

> 3) The source files are now in much deeper paths now, for example for the
> FASTA parser, the path is "src/main/java/org/biojava/fasta", as opposed to
> the common style "src/org/biojava/fasta", so I am wondering why it is
> necessary to add "main/java" in the middle of the path.

This is because of Maven. The src folder contains both source code and
test code, and within each you can have multiple programming
languages. The default behaviour, to store source code in a main
folder and test code in a test folder, and under each have a subfolder
for the programming language, seems sensible to me so I went with it.
It also allows the inclusion of resource folders at the same level as
the java folder, the contents of which automatically get built into
the resulting jars as top-level classpath elements.

> 4) It is interesting to see that you put the source codes of all the
> sub-packages separately, so whenever I need to browse the codes of some
> related classes in Windows explorer or Unix shell, I really need to go up
> and down by clicking or typing many more times. Netbean IDE alleviated this
> problem a little bit. I understand the idea of seperating independent
> packages in the new design, but I am wondering whether the current very fine
> seperation of classes went too far.

I did this for clarity's sake as to which source code related to which
module - you can see really easily if they're separated, whereas if
they were all in one tree, it would be hard to know which module a
particular class ended up in. Also if you have one source tree, you
have to remember to update the Maven configs to split different bits
of it into different jars. By simply keeping them separate, this
happens automatically.

Thanks again for your feedback!

cheers,
Richard

-- 
Richard Holland, BSc MBCS
Finance Director, Eagle Genomics Ltd
M: +44 7500 438846 | E: holland at eaglegenomics.com
http://www.eaglegenomics.com/