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

Wed Oct 29 12:30:29 PDT 2008

I think Dan's solution was a great improvement over the static system we had
before, as it allowed us to dynamically load jar files at runtime, which has
opened up new mechanisms for distributing kar files independently of the
Kepler release.  It could certainly be improved, but not at the expense of
losing this flexibility.  And I agree with Dan that users should not be
expected to have or understand ant or maven in order to run the system.  Any
classpath management at runtime needs to be handled by Kepler itself, not
via an external build system.  How the classpath is handled at compile time
could be more flexible, but it seems to me that there are advantages of
consolidating on the same runtime system, as this promotes consistence
between what is available while building and what is available when running,
which should help reduce unforseen problems related to classpath
differences.  So lets work on a new system, but not throw out the features
we cared about along the way.

Matt

On Wed, Oct 29, 2008 at 11:21 AM, Dan Higgins <higgins at nceas.ucsb.edu>wrote:

> Hi David and Tristan,
>   I am the culprit that initiated the InitClassPath idea (before I retired
> from NCEAS last Feb). It was far from an ideal solution (but a vast
> improvement over trying to keep a list of more than 100 jars up-to-date all
> the time).  Note that using ant was NOT considered a good idea at the time
> because we did not want to ship ant with Kepler, many novice users (not
> developers!) did not know what ant is, did not want to install it, and did
> not know how to use it. I encourage efforts to improve classpath handling
> but do suggest that developers try to hide the details from potential
> ordinary users.
>
> Dan Higgins
> NCEAS - (retired)
>
>
> David Welker wrote:
>
>> Hi Tristan,
>>
>> I agree with you that this InitClassPath idea was probably not a good one.
>> I know you have your own Maven build going on... but I should point out that
>> in the loader module used with the new build system, InitClassPath is no
>> longer used. If you are so inclined, you might want to check out the new
>> build system, especially the 1.1 branch. It is, in my opinion, a vast
>> improvement over the previous build system. (Note: I am, of course, biased,
>> since I have been the person who has primarily developed the new build
>> system.) But, perhaps more importantly from your perspective, InitClassPath
>> is not used, so this problem you are having will no longer exist. As you
>> suggest, in the new build system, I use ant to manage the class path, and it
>> does the job.
>>
>> David
>>
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20081029/5f5925c2/attachment.html>