[Biojava-l] Running apps with Java
Tom Oinn
tmo at ebi.ac.uk
Wed Aug 13 15:19:23 EDT 2003
Isn't this what the ACD files in EMBOSS are doing? Perhaps not
reinventing the wheel would be good? Admittedly ACD is not the most
parsable file format to work with, but we have an XML dialect of it
which is (part of Martin's Soaplab).
Martin - is the XML schema available somewhere? I can't find it from
the webpage...
Tom
Patrick McConnell wrote:
>
>
>
>
> For maximum flexibility and ease of use, I think describing the parameters
> in an external (editable) file would be preferrable. I do not think it
> would be too hard to come up with an XML schema for describing how programs
> should be run. Something like:
>
> <program>
> <name>NCBI Blast</name>
> <parameterSet>
> <platform>default</platform>
> <flag>-</flag>
> <delimiter> </delimiter>
> <parameter>
> <name>p</name>
> <description>blast program</description>
> <allowableValues>
> <allowableValue>blastn</allowableValue>
> <allowableValue>blastp</allowableValue>
> <allowableValue>blastx</allowableValue>
> </allowableValues>
> </parameter>
> . . .
> </parameterSet>
> </program>
>
> You could define defaults that can be overridden per program, per platform,
> and per parameter. This way, users can easily add/change programs for
> their platform, and you do not need to rebuild BioJava for these changes.
>
> The code for invoking the program would be like:
>
> ExternalProgram prog = new ExternalProgram("NCBI Blast");
> prog.addParameter("p", "blastn");
> . . .
>
> String stdin = null;
> StringBuffer stdout = new StringBuffer();
> StringBuffer stderr = new StringBuffer();
> prog.exec(pathToBlastall, stdin, stdout, stderr);
>
> You could also query a particular program for its parameters, allowable
> values, defaults, etc.
>
> Again, the file could be located and loaded from the BioJava jar, the
> directory the BioJava jar is in, and the user's home directory.
>
> I would love to see something like this in BioJava. Please comment on the
> advantages/drawbacks of such a system because I am now considering
> implementing it for my own use!
>
> -Patrick
>
>
>
>
>
> "Schreiber, Mark" <mark.schreiber at agresearch.co.nz>@biojava.org on
> 08/12/2003 10:39:04 PM
>
> Sent by: biojava-l-bounces at biojava.org
>
>
> To: "Keith James" <kdj at sanger.ac.uk>, "Thomas Down"
> <thomas at derkholm.net>
> cc: biojava-l at biojava.org
>
> Subject: RE: [Biojava-l] Running apps with Java
>
> I would tend to agree with Keith. Making hardcoded command lines can loose
> platform independence pretty quickly. I would prefer to see users register
> their own command lines, preferences etc with some kind of registry object.
>
> - Mark
>
>
> -----Original Message-----
> From: Keith James [mailto:kdj at sanger.ac.uk]
> Sent: Tue 12/08/2003 10:46 p.m.
> To: Thomas Down
> Cc: biojava-l at biojava.org
> Subject: Re: [Biojava-l] Running apps with Java
>
>
>
> >>>>> "Thomas" == Thomas Down <thomas at derkholm.net> writes:
>
> [...]
>
> Thomas> Yes, I quite agree. Although I think I'd prefer
> something
> Thomas> more like:
>
> Thomas> params.addParameter(NCBIBlast.PROGRAM_NAME,
> "blastn")
>
> Thomas> Have you looked at the AnnotationType class? We
> could
> Thomas> probably use those to do the parameter set
> validation.
>
> IMO having program names hardcoded in the method names or even
> as
> parameters greatly increases the amount to code required for a
> typical
> system. A public exec method per program will result in a lots
> of
> methods and requires rebuilding the jars to deploy a new
> external
> program (same with static parameters specific to a program).
>
> Having a single, generic exec method with a means of
> discovering local
> native programs is simpler and more maintainable. This can be
> done
> simply with ResourceBundles (which also means that one can
> internationalize for free)
>
> e.g.
>
> NCBIBlast_en_GB.properties
>
> -p = String : Program name
> -d = String : Database, default = nr
> -i = String : Query file, default = stdin
> -e = Double : Expectation value (E), default = 10.0
>
> etc.
>
> NCBIBlast_fr.properties
>
> -p = String : Nom de programme
>
> etc.
>
> I think it is important to allow end users to configure their
> biojava
> to run their native applications without writing any code.
>
> Thomas> The other big win would be to do something at
> least
> Thomas> vaguely sane about finding executables. Hardcoded
> paths
> Thomas> aren't a problem if you are running on your own
> machines,
> Thomas> but if people want to deploy BioJava-based
> applications
> Thomas> widely, they really need to be able find blast on
> their
> Thomas> own...
>
> You can do this simply by adding a key/value to the resouce
> giving the
> full path. Alternatively this keyed value could be the name of
> a JNDI
> resource etc. for situations which require it.
>
> I've been running a simple Java-based workflow & execing
> system in
> anger for the past year (lots of different native programs)
> and native
> program maintenance requiring rebuilding production of jar
> files is
> not something I'd want to deal with.
>
> cheers,
>
> Keith
>
> --
>
> - Keith James <kdj at sanger.ac.uk> Microarray Facility, Team 65
> -
> - The Wellcome Trust Sanger Institute, Hinxton, Cambridge, UK
> -
> _______________________________________________
> Biojava-l mailing list - Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>
>
>
> =======================================================================
> Attention: The information contained in this message and/or attachments
> from AgResearch Limited is intended only for the persons or entities
> to which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipients is prohibited by AgResearch
> Limited. If you have received this message in error, please notify the
> sender immediately.
> =======================================================================
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>
>
>
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>
More information about the Biojava-l
mailing list