[kepler-dev] org.monash.griddles.JCOG* actors and compile/runtime dependencies on globus

Kevin Ruland kruland at ku.edu
Sun Feb 12 16:59:55 PST 2006


Jagan,

I think $KEPLER is the base of the kepler install directory (as opposed 
to the cache location).  So, I suggest you put all the cog jars in a 
subdirectory of $KEPLER - lets call it $KEPLER/cog.  (or whatever).  
Now, each of your actors can then open this directory and enumerate all 
the files in it.  This list of files could then be the classpath for the 
subprocess.

Of course, having the jars in $KEPLER/cog is a completely different 
decision from where they go in the archive.  Since most developers 
execute with $KEPLER == the root of their cvs workspace, I think you 
should probably move the jars to the decided on location relative to the 
CVS base - then changing the build appropriately.

Kevin

jagan wrote:
> Hi Kevin,
>
> Thanks for your advise and suggestions. I know these jars are not 
> required to keep KEPLER classpath. Do you think, it is advisable to 
> create a separate
>
> cog-4_1_3 directory in $KEPLER for all the Globus jar files?
>
>
> JCOGWorkflowExec is still in the developmental stage, I need to add 
> few more capabilities to this actor, I will update this actor soon and 
> also I will remove hard coded path names.
>
> with regards,
>
> Jagan Kommineni
>
>
> Kevin Ruland wrote:
>
>> Hi all.
>>
>> I've looked at the 4 actors added recently to the org.monash.griddles
>> package which supposedly have dependencies on the 49 jars added to
>> lib/jars/cog-4_1_3.  The actors I've looked at are:  JCOGGridFTP,
>> JCOGPROXYExec, JCOGWorkflowEditor, and JCOGWorkflowExec.
>>
>> There are no compile time dependencies on any jars in cog-4_1_3 for any
>> of these actors.  I've looked pretty carefully at the code, and they
>> don't appear to reflect to classes in these jars either.  What they
>> appear to do is use exec to run java using the main method in the 
>> following:
>>
>> org.globus.cog.karajan.Loader
>> org.globus.cog.gridface.impl.gftpanel.GridFTPPanel
>> org.globus.tools.proxy.GridProxyInit
>> org.globus.cog.karajan.viewer.KarajanFrame
>>
>> It passes the current vm's classpath to the exec.
>>
>> I think it would be best if none of these jars are put on Kepler's
>> classpath.  Instead, these actors should hand off to the subprocesses a
>> classpath just for the use of the globus provided tools.  It would
>> probably work to construct the classpath by using the installed root
>> directory of Kepler (is this the KEPLER env var?), and append each of
>> the jar names seperately.
>>
>> Also, the JCOGWorkflowExec actor has some hard coded path names
>> "C:/qsb_amipxx-OUT/stdout", "C:/qsb_amipxx-OUT/stderr", which is doubly
>> bad.  They are window's paths and why exactly should these files exist?
>>
>> Kevin
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>  
>>
>



More information about the Kepler-dev mailing list