[kepler-dev] java cog jar files duplication .....

Dan Higgins higgins at nceas.ucsb.edu
Thu Jun 22 20:09:45 PDT 2006


jagan,
    From your example code, it appears that you are launching another 
JVM with its own classpath. That operation should be independent of any 
of Kepler's parameters, including the Kepler classpath. So I don't see 
how this secondary Java process can be interferred with by Kepler ???

Dan Higgins

jagan wrote:
> Hi Ilkay,
>
>
> Ilkay Altintas wrote:
>> On Jun 22, 2006, at 12:33 AM, jagan wrote:
>>
>>   
>>> Hi Ilkay,
>>>
>>> I am getting some duplicated jar files with the latest version of  
>>> java cog toolkit cog-4_1_4.
>>> As you know, cog supports number of different versions of globus  
>>> toolkits. They are loading some java classes
>>> based on the relative path of  the other jar files (those jars are  
>>> not in the classpath).  That means
>>>     
>>
>> Jagan,
>>
>> Was this not happening before? What initiated the problem?
>>
>>   
> I think this problem only with the latest version, it is not the case 
> before, you may have look at the cog's documentation.
> http://wiki.cogkit.org/index.php/FAQ#How_do_I_integrate_the_CoG_Jars_into_my_own_project.3F
>
>>> I have to maintain their directory structure as tease  at least for  
>>> some  jar files.
>>>     
>>
>> I couldn't understand this. Could you explain it further?
>>
>>   
> Cog's 4_1_4 library structure is some thing like this
> jagan at brama ~/cogkit/cog/dist/cog-4_1_4
> $ ls
> bin  etc  examples  lib  lib-gt3_2_1  lib-gt4_0_0
> There are number of jars in lib folder which are required to be in 
> classpath and there other jar files in folders lib-gt3_2_1 and  
> lib-gt4_0_0
> These folders are required to maintain the relative path but those 
> shouldn't go in "classpath". 
>
>
>>> I am  using their services  by calling an external process from the  
>>> kepler actor.
>>> I can create a completely seperate classpath based on cog jar files.
>>> That means I don't need pollute Kepler classpath from the cog  
>>> classpath.
>>>     
>>
>> You mean you won't include them in the classpath? Maybe you create a  
>> new configuration for your project?
>>
>>   
> I would like to put all the cog jars in $KEPLER/cog folder which is 
> not a regular kepler class path folder.
> I create a new classpath for cog taks from with in the kepler actor 
> and call a new sub process to handle this task as shown below.
>
> String wfCommnad =  "java -classpath "+cogClassPath+" 
> org.globus.cog.karajan.Loader "+ xmlScript;
> process = Runtime.getRuntime().exec(wfCommnad);
>>> Already I am storing cog's jar files in $KEPLER/cog directory by  
>>> using third party jars from kepler classpath.
>>> With the latest version I need to maintain relative path as I  
>>> mention before which ends up with some duplication in jar files of  
>>> Kepler's cvs repository.
>>>     
>>
>> I don't think relative paths is a good idea. I think it is better to  
>> go with a separate configuration file. That is if I understood you  
>> correctly.
>>
>>   
> I agree with you the relative path is not a good solution.
>
> with regards,
>
> Jagan Kommineni
>
>> HTH,
>> -ilkay
>>
>>   
>>> Could you mind to give some advise please?
>>>
>>> with regards,
>>>
>>> Jagan Kommineni
>>>
>>>     
>>
>>
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20060622/c13c49ac/attachment.htm


More information about the Kepler-dev mailing list