[Biojava-l] State of the nation

Mark Fortner phidias51 at gmail.com
Fri Mar 23 02:53:50 UTC 2007


Mark
As you point out, the build server changes (and potentially the bug tracking
system) would require the participation of the open bio folks to make these
changes to their server.  It might be a good idea to begin engaging them
now.  They may have some other ideas as well.

There are complete software development management systems like Source Forge
that could be setup.  When I worked at a previous company we had our own
internal SourceForge instance that gave us forums, a wiki, subversion, bug
tracking, etc. Atlassian offers a similar product suite.  Such an
all-encompassing solution might suit OpenBio more than a series of piecemeal
solutions.

Mark

On 3/22/07, mark.schreiber at novartis.com <mark.schreiber at novartis.com> wrote:
>
>
>
>
>
> *"Mark Fortner" <phidias51 at gmail.com>*
>
> 03/21/2007 01:22 PM
>
>         To:        "mark.schreiber at novartis.com" <
> mark.schreiber at novartis.com>
>         cc:
>         Subject:        Re: [Biojava-l] State of the nation
>
>
> Hi Mark,
> I started to edit the wiki, but then thought it might be better to discuss
> a few things first.
>
> (1) There are some new javadoc tags that can make some of this easier to
> do.  {@inheritDoc} for example can be used to inherit the documentation from
> an interface or superclass, thus saving some typing.
>
> Yes, we use these a lot in biojavax but it could be added as a
> recomendation in the wiki.
>
> (2) Unit tests will definitely make it easier to handle regression tests,
> but it might be better to simply add additional test methods to existing
> unit tests (currently located in the tests directory).  This directory
> mirrors the source packages and is fairly easy to maintain.  We can add a
> comment in the test method to indicate that it's in response to a particular
> bug fix.
>
> You could name the method testBug12345. It's a matter of style I suppose.
> Having it all together reduces redundancy. Having regression tests
> seperately makes it easier to find the appropriate regression test
> especially if it involves more than one object.
>
> (3) Regardless of the method used to build BioJava it would be useful to
> continuously build and test the project.  There are tools to do this for
> both Maven and Ant.  In addition to simply telling us that the build is
> broken, there are code coverage plugins that can tell us if the unit tests
> accurately cover the code they purport to test.  You can also generate
> documentation, HTML-browsable code (java2html), and UML diagrams (through
> UMLJGraph or doxygen) in an automated fashion.   Here's a partial plugin
> list to give you some ideas: *http://maven.apache.org/plugins/index.html*<http://maven.apache.org/plugins/index.html>
>
> I agree. I'm not much of a build expert and only an ant hacker. What we
> really need is some volunteers to help set this sort of thing up. If you
> know how to do it and have the time it would be excellent.
>
> (4) If you've reported bugs for any of the Apache projects, you may have
> noticed that they switched to JIRA.  This is a wonderful tool created by a
> company in Sydney called Atlassian.  The tool can provide users with a
> roadmap of what changes are due in which releases, you can create RSS feeds
> for different reports.  The reports are completely customizable.  If you use
> the Eclipse Mylar plugin, then tasks that are assigned to you in JIRA appear
> in Mylar.  You can also add JIRA issue numbers to code checkins in
> subversion or CVS.  When JIRA indexes the code, you it then provides you
> with a list of all classes that were modified in response to a particular
> bug.  There are numerous other features described here: *
> http://www.atlassian.com/software/jira/*<http://www.atlassian.com/software/jira/>and the software is available free of charge for open source project! s.
> *http://www.atlassian.com/software/jira/pricing.jsp*<http://www.atlassian.com/software/jira/pricing.jsp>
>
> Again, I don't have much experience. I use bugzilla because open-bio set
> it up for us. We could probably request other things if you know what you
> want.
>
> Go ahead and add some suggestions on either the wiki or the mailing list.
> Hopefully some prodding will provoke the slumbering biojava community into
> action : )
>
> - Mark
>
> Hope this helps,
>
> Mark Fortner
>
>
> On 3/20/07, *mark.schreiber at novartis.com* <mark.schreiber at novartis.com> <*
> mark.schreiber at novartis.com* <mark.schreiber at novartis.com>> wrote:
> Hi -
>
> Recently several of the current and former core developers of the biojava
> project happened to be in Cambridge at the same time and had some
> discussions about the directions and immediate future of the project. A
> summary of the discussion has been posted on the biojava website at*
> **http://biojava.org/wiki/BioJava:CambridgeDiscussion*<http://biojava.org/wiki/BioJava:CambridgeDiscussion>
>
> Please take a look and feel free to add your comments to the page.
>
> - Mark
>
> _______________________________________________
> Biojava-l mailing list  -  *Biojava-l at lists.open-bio.org*<Biojava-l at lists.open-bio.org>
> *
> **http://lists.open-bio.org/mailman/listinfo/biojava-l*<http://lists.open-bio.org/mailman/listinfo/biojava-l>
>
>
>



More information about the Biojava-l mailing list