On Wednesday 07 December 2005 17:44, Daniel Leidert wrote: > Am Mittwoch, den 07.12.2005, 17:06 +0100 schrieb Egon Willighagen: > > On Wednesday 07 December 2005 16:49, Daniel Leidert wrote: > > With 'almost' I meant: Bioclipse itself requires only free java tools. > > Some plugins may require non-free stuff (bc_jmol and bc_jcp) and this > > needs to be explored. Those would need to go into contrib. > > > > But to make it clear, bioclipse and bc_cdk: > > - can be build with free tools from main (as the build process matches > > that of eclipse) > > - can run with free tools from main (I have run it with jamvm and > > classpath) > > I did not have a look at the source yet. Will do it soon. JFTR: To get a > package into main it MUST NOT have any dependencies (build and runtime > deps) to packages outside main or precompiled stuff.
Actually... bioclipse and the plugins really only depend in eclipse, which is in swing, and a set of open source java libraries, which we might need to package up... The only problem why bc_jmol and bc_jcp are *not* currently running with tools from main, is a bug in eclipse (the SWT_AWT bridge problem...) So, I actually think all can go into main, if we realize that the jmol and jcp plugins won't run because of a bug in a main package... and not because it depends on non-free stuff. If we consider that it is not caused by the eclipse bug, but a dependency on non main stuff, then still we have: - bioclipse and bc_cdk will go into main - bc_jmol and bc_jcp will go into contrib Need to look at the other, newer plugins. (FYI, I have been in the new maintainers queue and have read the DSFG cover to cover, so I'm quite sure what it is about :) > > > > and making it straightforward for me to add it to > > > > the live chemblaics CD I want to release early next year for demoing > > > > our favorite software on our friends laptop. > > > > > > > > Now, Stephan is interested in making debs. Daniel, I was hoping you > > > > could help out here too, because the Jmol/JCP plugin debs will depend > > > > on debs for Jmol, CDK and JChemPaint... I've done deb packaging in > > > > the past too, so can offer testing etc here too... > > > > > > No problem with that. The whole work is available to the public (ok, > > > last solutions are still on my local systems, but if interested I can > > > put them online). It would like to see it in Debian. Today I again got > > > post asking, why several packages are not part of it :) > > > > Please do put them online, possibly with a brief explanation on how > > people can build the packages from the deb-src sources. > > I will try to get it up next weekend. But I stopped work at it some time > ago, because of several other projects. It would be quite easier if we > could solve several problems in upstream, so it makes the life for the > Debian package maintainer easier. That's my plan too. > > I really interested in getting > > things ready for debian, (k)ubuntu and the knoppix-based chemoinformatics > > live CD I want to have ready in May 2006. > > Of course. > > > > > Some questions I currently have (Stephan, Daniel, others, please add > > > > yours): - how can be build the things from the command line? > > > > > > Sorry, I don't understand. What do you mean with "build the things from > > > the command line"? > > > > We need a build process for bioclipse framework and the bioclipse > > plugins. This will require to build them from the command line, i.e. > > using the default Debian build process/daemons. > > Ant build oder GNU make process? > > [..] Ola and I have been talking to Stephan Michels (co-maintainer of the eclipse packages), and he informed us about the option to create Ant build files for eclipse plugins. Ola is currently exploring this. Stephan indicated that we will help us create the debian packages for bioclipse, where possible... > > > > - can we resolve the circular dependencies between the current > > > > Jmol/CDK debs? > > > > > > That's a question for upstream. > > > > Upstream: that's me right? > > Yes. Jmol and cdk maintainers/project leaders should make this > decision :) I already started a discussion some time ago. I will try to fix this before christmas. > > > The current solution is, that there is a > > > target in Jmol's build.xml to make a package for the jmolApis.jar and > > > jmolIO.jar (IIRC you wrote that). But it still requires heavy patching. > > > > Can you point out to me what patching you need to do, then I can fix > > things upstream. > > There is a lot of stuff, which needs to be done manually to have a clean > source for a debian package. > > - the source file for jmolApis.jar and jmolIO.jar should not be compild > when compiling Jmol (because it depends on jmolApis.jar and jmolIO.jar > from the "other" package") > > Patching stuff: > > - jar archives provided by Debian should be used instead of the > pre-compiled stuff in jars/ or libs/ (same for the docbook stuff). Yes, I remember that from the deb packages I used to create... > Similar problems inside the cdk source (and because of the circular > dependency with JoeLIB some more). I've added some variables to the > build.xml file in the Debian package to make the determination for > several jars available as command line option. Maybe this is a possible > solution for these problems. > > Maybe(!) it would be better to also(!) have a GNU make framework, where > configure can determine the whole locations, paths, .... But this is a > lot of work. OK, thanx for these hints. Now I know where to start cleaning it up. What is your position on not compiling part of the source? Say, when packaging CDK, not compiling the JOELib interface? So to drop the dependency on JOELib? The ant build script is quite capable of detecting absence of certain libraries and conditionally (not) compile parts, much like in autoconf/-tools set ups... Taking this further, I can even think of this setup: cdk-src.orig.tar.gz -> cdk.deb and libcdk.deb, depending on little (using debian-lib/ subdir) cdk-src.orig.tar.gz -> cdk-jmol.deb, depending on libcdk.deb and jmol.deb (using debian-jmol/ subdir) The two debian/ subdir conveniently not compile certain parts of the CDK source code... Is that acceptible? > > > It would be better to find a clear solution, which can be implemented > > > in upstream, e.g. moving the cyclic stuff to the cdk sourcs and build > > > cdk-jmol.jar. And BTW: There is another cyclic dependency between > > > JoeLIB and cdk (cdk-libio.jar). > > > > OK, lets disregard JOELib for now, as the future of that project is > > (unfortunately) uncertain at this moment... > > There are no dependencies to cdk-libio.jar? No, generally not. CML libio is used more often, but still only needed for writing CML. Wrt to the JOELib interface, it's really an interface and not required by any CDK algorithm what so ever... So dropping it, would not reduce the functionality of the CDK itself, only the option to interface with JOELib classes. Egon -- Egon Willighagen http://chem-bla-ics.blogspot.com/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
