From: Jeff A. <ja...@fa...> - 2018-09-14 09:50:03
|
Yes, -cp ignored with -jar is a Java command thing. (I assume there's a good reason.) You can specify a classpath in the JAR. (https://stackoverflow.com/questions/15930782/call-java-jar-myfile-jar-with-additional-classpath-option) It's really two proposals: remove -jar option (as it hasn't worked, so probably won't be missed); and deprecate runJar(). Jeff Allen On 14/09/2018 09:34, Adam Burke wrote: > > java -cp JyNI.jar -jar jython.jar > This would be clean, useful, and feel right to me as a user. > Adam > > On Fri, 14 Sep 2018 at 18:17, Stefan Richthofer > <ste...@gm... <mailto:ste...@gm...>> wrote: > > No real opinion from me here, deprecation sounds better to me than > complete removal. However now that you are looking into this I > wanted to ask about this thing that bothered me a bit since I > started with Jython: > I always found it cumbersome that it isn't possible to run > > |java -cp JyNI.jar -jar jython.jar| > > Well, it runs but the -cp option is like ignored in this case. > Same if I try > > |java -cp jython.jar:JyNI.jar -jar jython.jar| > > One has to use one of these variants: > > |java -cp jython.jar:JyNI.jar org.python.util.jython| > > |jython -J-cp JyNI.jar | > > That means for me, the most natural/intuitive way to launch Jython > with additional jars on the classpath does not work. Especially > when I was getting started with Jython I tried to use it as an > ordinary jar in terms of launching. I found it confusing that -cp > didn't work. Do you se a way to fix this? Or is this a JVM limitation? > > > Am Fr., 14. Sep. 2018 um 09:21 Uhr schrieb Jeff Allen > <ja...@fa... <mailto:ja...@fa...>>: > > The question is a lot like that of SystemRestart, although I > haven't > done as much code archaeology. At present, we appear to > support an > option -jar to the jython command. Just type jython -h or see: > > https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91 > > But we don't. When you try to use it, all that happens, and > has happened > for a while, is this: > > PS startup2> jython -jar test.jar > C:\Jython\2.7.0\bin\jython.exe: No module named __main__ > > The reason it doesn't work as promised is that before we try > to run the > JAR, we try this: > > https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316 > > and since the attempt to get an importer for a JAR is > successful, that > method returns true, and so we never check the -jar option. > The handler > runMainFromImporter() can't run it, because it expects a > __main__ module > (the -jar flag expects a __run__.py instead), and that leads > locally to > a System.exit(). > > Functionally, runMainFromImporter(), which was added in 2.7 to > implement > CPython behaviour, is very similar to the much older runJar() > although > not exactly the same. I think if we were doing this now, we'd > only > provide that later mechanism. CPython can run exactly the same > JAR (with > a __main__.py) that I'm using to test runMainFromImporter(). > > When I correct the logic so that -jar calls runJar() as it > used to, it > doesn't work that well anyway: the script runs, but my import > produces > warning messages about the (assumed) package name of my > script, and what > ought to be the source code context in the message looks like > binary > from the JAR. However, runJar() is public so maybe there are > applications that call it. > > I'll make a commit with the -jar option restored for > comparison, but I > think the command option could be removed immediately and a > deprecation > warning slapped on runJar(). > > Any contrary thoughts? > > Jeff > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |