[kepler-dev] jar file locations

[Douglas Fils]

All,
    Hello, this is Doug Fils with the CHRONOS (http://www.chronos.org)  
project and I am new to the list here. We have just started doing some 
work with kepler and are interested in using it with our webs 
services.    I have 2 comments for the list.

1) I don't know if it would be useful as it relates to your issues with 
the jar files, but the IBM package at:
http://www-106.ibm.com/developerworks/library/j-onejar/index.html?ca=drs-j4904
talks a bit about the issue of combining jar files and has some good 
references at the bottom.  I don't know how well it addresses the 
signing issues related to web start though.

2) I am still having trouble getting the versions of the kepler program 
for windows at mac os x which recently got linked in at the new wiki 
site to work with web services (the linux version works fine btw).  This 
is in relation to web services work flows only.  We made a test workflow 
at: http://test.chronos.org/wsFlowv2.xml that we have been using to test 
the keplers installs with and seem to have issues as noted on windows 
and mac os x. 

thanks all!
I'm looking forward to digging deeper into kepler and using it more at 
chronos.
take care
doug


Ilkay Altintas wrote:

>
> Dan,
>
> I think we need to clean the jars as well. I had to deal with the same 
> problem when working on the webstart generation.
> It didn't break the version in august when I reduced the duplicate 
> jars into one.
>
> Another problem I have when generating the webstart is on signing some 
> of the jars.
> It looks like some jars have to keep their original signature so when 
> I remove the originals and resign them the actors that use them break.
> If I don't sign them, the webstart doesn't work because all the jars 
> need to be signed by the same signature.
> Does anybody have a suggestion on how to solve this?
>
> Thanks very much!
> Ilkay
>
>
> On Dec 6, 2004, at 11:41 AM, Dan Higgins wrote:
>
>> Christopher,
>>
>>    Thanks for the response. The name problem is that the actual jar 
>> file name is repeated in different subdirectories; e.g. 
>> "$KEPLER/soap/soap.jar" and "$KEPLER/apache/soap.jar". We are thus 
>> ending up with duplicates (or different versions with the same name) 
>> in the class path. Part of the problem is that we now are ending up 
>> absurdly long classpaths! This seems to be OK on WindowsXP but causes 
>> a problem on Win2K. Various Kepler deveopers have added the many jar 
>> files to support their specific actors so we don;t even include the 
>> source (or recompile) for these jars.
>>
>> Dan
>>
>> Christopher Brooks wrote:
>>
>>> Yikes!
>>> 90 jars is a lot.
>>>
>>> I probably don't fully understand the issue, but the problem I see
>>> with flattening the directory structure is that it becomes difficult
>>> to see what jar files belong together.  This can make shipping a
>>> subset tricky and it can make upgrading to new releases of distributed
>>> packages tricky.
>>>
>>> I'm not sure I understand how directories and jar files can have the
>>> same name?  Aren't $KEPLER/lib/jar/soap and $KEPLER/lib/jar/soap.jar
>>> two separate names?
>>>
>>> BTW - How Ptolemy handles jar files is that the makefiles in each
>>> leaf directory build a jar file that contains the appropriate files
>>> and then directories that are the parent directories of leaf
>>> directories include the jar files in the leaf director.  For 
>>> example, sdf/sdf.jar includes sdf/lib/lib.jar and sdf/kernel/kernel.jar
>>>
>>> I'm not sure if that would help here.
>>>
>>> _Christopher
>>>
>>> ----
>>>
>>>    Hi All,
>>>        I have been looking into ways to simplify the Kepler 
>>> structure in    CVS (and for distribution). One of the current 
>>> complexities is the large    number (~90) of jar files under the 
>>> $KEPLER/lib/jar/ subdirectory.
>>>           One problem is the number of subdirectories under the    
>>> $KEPLER/lib/jar/ subdirectory that just contain jar files. This    
>>> additional subdirectory structure creates the possibility of jars 
>>> with    the same names.
>>>       Is there anyone who knows of a problem that will occur if we 
>>> just    'flatten' the subdirectorys and put ALL the jar files 
>>> directly in the    $KEPLER/lib/jar/ subdirectory?
>>>       This seems to work OK (if I just use the newest version of 
>>> some of the    repeated jars), but I don't want to break anyone's 
>>> actors by mistake.
>>>       Dan
>>>       --    
>>> *******************************************************************
>>>    Dan Higgins                                  higgins at nceas.ucsb.edu
>>>    http://www.nceas.ucsb.edu/    Ph: 805-892-2531
>>>    National Center for Ecological Analysis and Synthesis (NCEAS)    
>>> 735 State Street - Room 205
>>>    Santa Barbara, CA 93195
>>>    *******************************************************************
>>>       _______________________________________________
>>>    kepler-dev mailing list
>>>    kepler-dev at ecoinformatics.org
>>>    http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>> --------
>>>
>>
>>
>> -- 
>> *******************************************************************
>> Dan Higgins                                  higgins at nceas.ucsb.edu
>> http://www.nceas.ucsb.edu/    Ph: 805-892-2531
>> National Center for Ecological Analysis and Synthesis (NCEAS) 735 
>> State Street - Room 205
>> Santa Barbara, CA 93195
>> *******************************************************************
>>
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev