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:[EMAIL PROTECTED]
Sent: Tue 12/08/2003 10:46 p.m.
To: Thomas Down
Cc: [EMAIL PROTECTED]
Subject: Re: [Biojava-l] Running apps with Java
>>>>> "Thomas" == Thomas Down <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Microarray Facility, Team 65 -
- The Wellcome Trust Sanger Institute, Hinxton, Cambridge, UK -
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
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 - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
