[crossposted to several lists; be thoughtful in replying]
Greetings
JUMBO4.6 is now committed to SF (cml.sf.net) I have checked it out, built and run one app (Jmol)) It seems to work, though this is not a clean machine. check out module jumbo4.6. This is now the primary maintenance version and we shall gradually transfer maintenance from wwmm CVS. The CVS is quite large as we have added all the jars (see below). We have also added publications and other guidance. Although it's large it is probably best to check it all out rather than trying to use your own jars
We thank all the Java Open source chemistry community. At present JUMBO includes Jmol, CDK and Jchempaint jars
The main target at present is robustness, documentation, portability, etc. and contributions are very welcome.
There is a problem with jars which we might be able to tackle as a community. At present every Java Chemistry project includes third party jars. Examples are:
vecmath, printf (stable?)
gnujaxp, xerces, and other XML parsers (a real problem)
jars for processing the build but not required in the final exe fop, batik, saxon, jtidy
This gives rise to a range of problems:
- the size of the distrib is large
- some jars get out of date or become incompatible with the latest Java. Some has OS dependence
- there are often multiple jars in a distrib. These give rise to horrible errors such as NoSuchMethod
- we spend lots of time on messy maintenance
My suggestion is that our community try to rationalise at least some of this. Suppose we had a site
chemjars.sf.net
whose primary role was to offer the best selection of stable jars for our projects. If our distrib required (say) vecmath we would copy it from chemjars, rather than include it in the distrib. (The bioscience community, e.g. myGrid/taverna does this, I think). There could be a standard ant file on chemjars that was simply called for each function.
Current distributions would be smaller, robuster, etc. There would be a greater communal knowledge of problems.
The major remaining problem seems to be XML. This continues to drive us wild. So far it seems:
- XML is OS dependent. Am I right that Jmol requires gnujaxp if it is to run XML on Mac, for example
- Xerces (at least) has a new version every new moon. They are all incompatible AFAICS. I can no longer run validation on XML - the last tool (ASBuilder) disappeared and the new XML validation language in Java 1.5 tells us that it doesn't understand the XML Schema namespace!!!
- Xerces is now embedded in Java 1.5 and causes additional interactions with any Xerces in the distrib. (I think JUMBO has at least two if not 3 xerces from other thirdparties!).
Any of you checking out JUMBO will see the problem. I'd be grateful for - Jmol (Miguel) - how does Jmol parse XML (CML) - what parser does it use, etc? - JCP (Egon) - same for JCP
Also I think CDK had some hardcoded XML parsers (e.g. if you can't find Xerces use Aelfred). I think this causes prob elms which chemjars would overcome. Everyone would be able to know what they should use.
Best
P.
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
