[Biojava-dev] next steps
andreas.prlic at gmail.com
Fri May 29 00:53:22 EDT 2009
> I think each jar probably needs its own svn trunk. This is how apache
> commons is setup. The advantage of this is that everything is modularized
> with nice defined boundaries on dependencies. If you have once source tree
> that builds multiple jars then it becomes very easy to grab a class from
> another jar and forcing additional dependencies.
sounds good. Guess it might be good not to have too many .jar files
in the end as well.
> You also don't need to worry about a single user having access to the entire
> source tree. If you have a new developer who wants to get involved with a
> specific interest then easy to give him access to that package without
> worrying about breaking other packages.
might be useful in the future. For now I think it is good enough to
give developers write access to all of biojava.
> Do you think we should call the functional grouping packages or modules or
> something else?
What about: we call a toplevel project, a package. A package can then
consist of several modules. Not sure if we should have a jar per
package or per module.
> If you take a wack at the refactoring based on X number of modules then you
> could check each one in a different subversion trunk. Each module will
> probably have a dependency on biojava-core which will also be a separate
> subversion trunk. In Netbeans I would setup a project for each and then I
> can add the biojava-core project as an external project dependency.
Sounds good and you would do the same in eclipse.
> also allows each module to be released independently and more frequently. We
> probably need to come up with a versioning convention that is part of the
> jar name.
I think we should stick to the maven naming conventions.
groupId org.biojava.phylo for the phylogenetic package
version 3.0.0 or 3.0.0-SNAPSHOT if it is a nightly build
Not sure if any of the ant build tools automate the upticking of
> major/minor version number when packaging jars.
Not sure about ant, but maven has a built in release plugin. if it is
set up correctly you can just write
and the release is being prepared...
> As part of the refactoring now is the time to make any major namespace
> changes you want to make. I assume that eclipse refactoring makes this easy.
Namespace changes are tricky. In principle I don;t want to break
backwards compatibility with the existing code base. On the other side
having package names starting with org.biojava.structure, rather than
org.biojava.bio.structure would be simpler. If in doubt I am for
backwards compatibility. One case where I would like to see a change
is the core blast parsing modules. org.biojava.bio.program.sax does
not indicate at all that this has to do with blast.
More information about the biojava-dev