[Biojava-dev] next steps

[Michael Heuer]

Andreas Prlic wrote:

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