[kepler-dev] what's the deal with org.kepler.loader.InitClassPath?
Dan Higgins
higgins at nceas.ucsb.edu
Wed Oct 29 12:28:04 PDT 2008
David,
Good point! One possible pitfall is that parts of ant assume a SDK
version of Java is available (i.e. one with the compiler etc). Many
users may only have the JRE version of Java which does not have all the
support classes. Kepler installers will need to make sure that all the
classes used by ant are included.
Dan Higgins
----
David Welker wrote:
> Without getting into questions concerning Jython, I wanted to briefly
> address one point made by Dan.
>
> Similarly, many users don't know what ant is, don't have it installed,
> or know how to use it.
>
> It should be noted that Ant can be used to manage the class path, even
> if users do not know about Ant or have Ant installed. Ant is just
> Java. All the classes associated with Ant are stored in jars, most
> prominently ant.jar. It is perfectly possible for any Java program to
> use all the features of Ant in the background without the user knowing
> or caring or having ant installed, as long as ant.jar is included in
> the lib directory.
>
> David
>
> On Wed, Oct 29, 2008 at 12:02 PM, Dan Higgins <higgins at nceas.ucsb.edu
> <mailto:higgins at nceas.ucsb.edu>> wrote:
>
> Hi All,
> As Christoper noted, Jython was originally removed from Kepler
> due to its helping to make Kepler startup very slow. That problem
> was fixed and the base part of Jython is in Kepler 1.0 so that the
> Python actors from Ptolemy will run in Kepler. Note that it was
> fixed in Kepler by changing startup so that actors are
> instantiated when actually used.
> It would be nice to have all possible Jython classes available
> if the startup problem can be avoided. However, the number of
> users/developers that actually want to use Jython had not been
> very large in the past; maybe the demand has increased.
> Note also that in previous version of Kepler, we tried to avoid
> using environment variables for setting paths, primarily because
> we ran into a number of potential users (not developers!)
> (especially on Windows) who don't have a clue as to what an
> environment variable is and how to set it! (Similarly, many users
> don't know what ant is, don't have it installed, or know how to
> use it.) So if we add more pieces to the jython installation, we
> do need to consider how to make its use as easy as possible.
>
> Dan Higgins
>
>
> Christopher Brooks wrote:
>
> 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>
> <mailto: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
> <mailto:Kepler-dev at ecoinformatics.org>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> <mailto:Kepler-dev at ecoinformatics.org>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
More information about the Kepler-dev
mailing list