[kepler-dev] what's the deal with org.kepler.loader.InitClassPath?

[Christopher Brooks]

Hi Chad,

BTW - one reason that Jython was removed was because it wanted to
traverse the entire classpath and create cache files of all the
jars.  This made Kepler's start up time very slow.
This has probably been addressed because Kepler should no longer
be instantiating every actor at start up.  However, this is
something to watch for, these issues have a way of coming back.

The full version of Jython was fairly large, which is why Ptolemy
includes only a portion of it.  A separate module for Jython
would mean that all of Jython could be made available.

The Jython developement effort was on hold for a few years, but
there was some activity within the last year or so.

_Christopher

Chad Berkley wrote:
> Hi Tristan,
> 
> I think this class is there so that the classpath can be amended to 
> allow for different versions of the same class in different jars.  I 
> think Dan Crawl last worked on it, so I'll let him explain more.  I 
> think it's a bug that it finds files in the .svn directories.  They 
> should probably be explicitly excluded from the search as we will never 
> want anything in those directories in the classpath.
> 
> We have plans to overhaul this system sometime in the next year when we 
> start re-architecting the core of kepler.
> 
> As for including all of jython in kepler, I don't have a problem with 
> that as long as it isn't 20 MB of jar files or something huge like that. 
>  We're in the process of breaking kepler up into modules which will be 
> built by a single build system.  A Jython module would probably be a 
> nice addition to kepler.  I'm hoping to have the new directory structure 
> for the modules sorted out in the next week or so and I'm almost at a 
> point where I can check in the changes that I've made to split the core 
> of kepler away from other functionality.  Needless to say, there are 
> some pretty large changes coming to Kepler in the next couple weeks. You 
> might want to wait just a bit until we get this new system in place 
> before adding Jython.  We'll make an announcement to the community when 
> everything is ready to go.
> 
> thanks,
> chad
> 
> 
> Tristan King wrote:
>> I've been messing around with kepler's jython support recently trying 
>> to get kepler to use my system's jython install rather than the 
>> jython.jar included with kepler and run into an interesting problem.
>>
>> The InitClassPath class recursively goes through the lib/jar/ 
>> directory and adds anything it finds to the classpath. This includes 
>> the .svn/**/*.jar.svn-base files. Thus, even if i overwrite the 
>> lib/jar/jython.jar file, the 
>> lib/jar/.svn/prop-base/jython.jar.svn-base file is found and added to 
>> the classpath, and since . comes before j, the .svn/ version of 
>> jython.jar takes precedence in the classpath. I haven't tested this, 
>> but assume that this would effect any other files in the lib/jar/ 
>> directory. If you try and update a library, you wont be able to test 
>> it until you check the file into svn, which overwrites the stored .svn 
>> version of the file.
>>
>> Is there any advantage to the InitClassPath class other than removing 
>> the need to write out the classpath manually in release builds? 
>> Because I can't see one, and I don't think the aforementioned reason 
>> is a good reason for trying to build something that ant provides 
>> already, and does right!
>>
>> -- 
>> Tristan King
>> Research Officer,
>> eResearch Centre
>> James Cook University, Townsville Qld 4811
>> Australia
>>
>> Phone: +61747816902
>> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au> www: 
>> http://eresearch.jcu.edu.au
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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

-- 
Christopher Brooks (cxh at eecs berkeley edu) University of California
Chess Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst Chess/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax: 510.642.2718	      (office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480