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

[jagan]

Kevin,

I have created a cog sub directory under $KEPLER directory for storing 
all COG jar files.

I have created CLASSPATH pointing to all these jars before passing over 
to a sub process for executing COG tasks.

I have also eliminated hard coded paths by replacing with File Parameter 
variables.

These actors are in the developmental stage and I am also planning to 
add some more features soon.

Once again thank you very much for suggestions. I will be more than 
happy to receive any suggestions and comments.

with regards,

Jagan Kommineni


Kevin Ruland wrote:

>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
>>> 
>>>
>>>      
>>>
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20060213/3471f3fa/attachment.htm