[Biojava-dev] Rationalisation

Thomas Down td2 at sanger.ac.uk
Tue Feb 24 04:24:23 EST 2004


On 24 Feb 2004, at 03:15, mark.schreiber at group.novartis.com wrote:

> As you all know biojava is quite big. It currently splits itself into 
> two
> jar files (biojava.jar and grammars.jar) or three if you include the
> bytecode.jar.
>
> There have been suggestions of splitting it into subprojects. One 
> obvious
> place for a split would be biojava.jar and grammars.jar. The ant build
> already achieves this artificially by splitting the code base in two.
> Would it be sensible to give grammars it's own cvs home?

Actually, I think grammars.jar is probably a bad example: it was only 
being produced as a separate jar file for the convenience of the build 
process.  This got fixed in the build.xml clean up a month or so back: 
if you've still got a separate grammars.jar file lying around, it's 
from an old build and you should probably get rid of it.  Unless 
there's someone who seriously wants to use the grammars without the 
rest of biojava, I'd vote to keep them in their current place.

On the other hand...

> Other possible splits:
>
> demos
> doclets
> apps

Yes, all of these are possibilities.

Any taglets we use which might be of general interest should probably 
go to a general-purpose hosting site like jakarta.

Splitting the demos out it an interesting idea since it means that 
users have the option to download them without grabbing the complete 
(big!) biojava-live tree.  We should do this iff:

   - It makes the demos more, not less, visible to users (and core
     developers).

   - We can make sure they stay in sync with the core API (I can
     probably solve this one by adding them to the Autobuilder).

Another possible split, which has been talked about for a long time but 
never really happened is to separate out "general purpose" parts of the 
biojava API from "biology-specific" parts.  This still seems like a 
good idea in principle, but at this point it might be best to leave it 
for biojava 2.


     Thomas.



More information about the biojava-dev mailing list