[Biojava-dev] Vecmath in biojava

[Jose Duarte]

Thanks for the reply Andreas. Some comments below:


> Fewer dependencies is better. However since Jama is used extensively 
> at the internals, probably a dual dependency on both vecmath and jama 
> is the way to go for now.
>

Yes I agree it is the way to go for now. In any case it would be good to 
keep in mind that JAMA would be redundant if vecmath was introduced.


> We can provide utility methods such as Atom.getPoint3D(), 
> StructureTools.getPoint3dCAArray(structure) , etc. if people think 
> that would be helpful.
>

Alright, that sounds like a reasonable thing to do. I can add some of 
those already if I need them for the ASA implementation.

>
> Yes you can and need to. In prob. 85% of all situations that will go 
> perfectly as expected. However if the Java VM has vecmath bundled with 
> it, it will load the JVM's vecmath.jar instead of your application's 
> and then there is a high chance that there will be conflicts due to 
> API changes. Since we try to run on a wide variety of systems and 
> setups, we should therefore assume an older vecmath version when 
> writing biojava code.

Ok, thanks for explaining that. I think now I understand the problem. It 
never occurred to me in practice because I work 95% of the time in Linux 
and the JREs don't come bundled with java3d. In fact it is actually 
quite difficult to convince your Linux to point vecmath to the system's 
one ;) Anyway now I see that conflicts can happen with the system's 
vecmath, in fact I've just read that it seems to be bundled by default 
in Mac ( https://forums.oracle.com/thread/1274789).

So in my opinion the solution to the problem would be:

1) bundle-in the vecmath library with biojava, if I understand it 
correctly that's compatible with the vecmath licensing

2) take care of the maven classpath order and make sure that the vecmath 
import comes from biojava's provided jar and not from the system's one, 
thus making sure that the system's vecmath is always overridden by 
biojava's. From what I've been reading around, it seems that from maven 
2.0.9 the ordering of dependencies in the pom will be respected. Not 
sure how that applies to system libraries though. Does anyone have 
experience with this?

>
> Yes. Having said that, the goal is always to keep dependencies to a 
> minimum and only add new ones when we really need them. As such I just 
> committed a cleanup that removes the log4j dependency (it was only 
> used in a few files). The structure module now only depends on other 
> biojava modules (with the exception of the unit tests, but those are 
> not part of a release).

Alright thanks for that! I agree that it is a good idea to keep 
dependencies to a minimum. But it is also true that some basic things 
are unavoidable. So vecmath could be an example but also something like 
a logging framework if logging was to be done extensively throughout the 
code

Cheers

Jose