[Biojava-dev] next steps

[Andreas Prlic]

> 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.

This
> 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.
http://maven.apache.org/guides/mini/guide-naming-conventions.html
e.g.
groupId org.biojava.phylo for the phylogenetic package
artifactId biojava-phylo
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
mvn release:prepare
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.

Andreas