[Biojava-dev] Rationalisation

[mark.schreiber at group.novartis.com]

Your right! Grammars.jar has gone!

I should pay more attention :)

OK, splitting Grammars can wait for BJ2. I certainly don't want to make 
anyones job harder but demos and apps are an obvious target and would 
cause minimal pain to excise it from the main code base. I think this 
would also mean that at least one of the commons jar files could be moved 
in with the demos/apps group further reducing confusion about which jars 
are required and which ones are 'optional'.

- Mark Schreiber





Thomas Down <td2 at sanger.ac.uk>
Sent by: biojava-dev-bounces at portal.open-bio.org
02/24/2004 05:24 PM

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



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.

_______________________________________________
biojava-dev mailing list
biojava-dev at biojava.org
http://biojava.org/mailman/listinfo/biojava-dev