[Biojava-dev] Rationalisation

[mark.schreiber at group.novartis.com]

OK -

Maybe it's a hack and slash approach. I think for BJ2 there is a good 
argument for splitting Sybolic and Ontology APIs from the Bio stuff. 
Generating too many JARs is a bad idea.

Actually I think that splitting BioSQL support is a good idea (and maybe 
merging with DAS, Ensembl, etc). Not everyone uses it and it would give 
you the option of getting the BioSQL jar that supports the schema version 
you want.

- Mark





David Huen <david.huen at ntlworld.com>
02/24/2004 04:59 PM
Please respond to smh1008

 
        To:     Mark Schreiber/GP/Novartis at PH
        cc: 
        Subject:        Re: [Biojava-dev] Rationalisation


On Tuesday 24 Feb 2004 3:15 am, 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?
>
> Other possible splits:
>
> demos
> doclets
> apps
>
> My reasoning is as follows. Projects should be merged where components
> have a high level of two way dependency and seperated where there is 
only
> one way dependency.
>
> For example biojava depends heavily on grammars.jar but grammars.jar
> doesn't care too much about the core of biojava. Demos and apps are
> dependent on biojava but the reverse is not at all true. The doclets
> project is a nice add on but they are pretty indenpendent of each other.
> My feeling is that this would make management of the project much easier
> and ant scripts simpler.
>
> Any thoughts or flames??
>
By that rationale, classes related to bioSQL would sensibly lie outside 
the 
main package, as would the DP stuff. Perhaps we could put all the SQL 
implementation stuff (bioSQL, Ensembl) into one jar and things like DP 
into 
another exotics-that-will-do-your-mind-in jar.

My only reservation aobut all this is whether it would make for (perhaps) 
more support work when users get confused as to which jars they should 
have 
had in their classpath.

Regards,
David Huen