|
From: <bc...@wo...> - 2001-03-27 10:47:40
|
[Moved to jython-dev and cc'ed: liftoff-users] [Brad Clements] >I'd like to add support for NetWare in the installer.. How do I go about doing that? Start by checking out the CVS version of liftoff. http://sourceforge.net/projects/liftoff/ Build liftoff by running "bootstrap" and then "build" from within the "src" directory. Before running liftoff, some directories must be configured in the data/builder.properties file: # name of the list of stdandard files stdlist=i:\\java\\liftoff\\data\\def_list.list # name of the directory that contains the installer classes installer=i:\\java\\liftoff\\data\\installer # Jar loader class install_class=i:\\java\\liftoff\\data\\Install.class In src\installer\net\sourceforge\liftoff\installer you will find a os.properties file that maps the os.name to a platform action class. A new action class must most likely be created: NetwareAction.java. Use the WindowsAction class as a beginning. >The OS type reported (on my platform) is "NetWare 5.00", though "NetWare*" should >be used to match any version of NetWare. > >To install, the .class needs to be unzipped somewhere (I suggest sys:Jython) By default the installer picks the user.home property. If that property is initialized by the netware JVM, we should just use that. >(yes, that's right, "sys:Jython" NetWare uses volume:path/path/file) Perhaps the path handling code in liftoff can deal with that already. Perhaps not. >After unzipping to the target directory (wherever the user specified, might be >vol1:jython) these steps are needed: > >1. Add jython.jar to classpath by appending a line like this to the file sys:etc/java.cfg > >CLASSPATH=$CLASSPATH;sys:Jython/jython.jar > >(substitute the correct path) I don't yet have a wellformed opinion about this, but I would prefer if the installation set the classpath in the script files if at all possible. Not only does that match windows and unix behavior, it also avoids a lot of problems with proper access rights to sys:etc (I guess). >(anyone know if SERVLETCLASSPATH should be updated as well?) These changes to sys:etc/java.cfg should instead be described in doc/readme files. >2. Create two files in the target installation directory, like this: > >filename: jython.ncf > >Contents: > >java -ns -Dpython.home=sys:jython org.python.util.jython %1 %2 %3 %4 %5 %6 %7 %8 %9 > > >Note that the correct path needs to be inserted in place of "sys:jython", there's just one >line in the .ncf file. > >filename: jythonc.ncf > >Contents: > >java -ns -Dpython.home=sys:jython org.python.util.jython >"sys:jython/Tools/jythonc/jythonc.py" %1 %2 %3 %4 %5 %6 %7 %8 %9 > >(should be all one line, also put the correct path to sys:jython in both locations) That's relative easy with liftoff. A new builder property "exec.template.netware" must be added to liftoff and two jython specific template files must be added jython. >3. Admonish the user after installation with the following message: > >------ >You must unload java to complete the installation. Unload java by typing the command >"unload java" at the system console. Note that this will unload any DirXML drivers you >may have loaded. > >You may wish to add <installationdir> to the system search path by adding the following >line to sys:system/autoexec.ncf: > >search add <installationdir> >----- >(replace <installationdir> with the appropriate path to where the .ncf files ended up) > That is easy with liftoff's templates. >If someone could tell me how to make these changes to the installer (and submit a >patch) or if someone could just make the changes and I'll test (hint hint) I'd would be >very happy, and so would many NetWare users.. Absolutely. Making it easier for netware users to use jython would be a good thing for all. When I create the installable jython-21a1.class I run this windows script from within the jython CVS directory: java -Ddatadir=i:\java\liftoff\data -cp i:\java\liftoff\lib\LiftOff.jar net.sourceforge.liftoff.builder.Main where i:\java\liftoff is the CVS version of liftoff. I open the installer\liftoff.props file with the file/open and create the class with Create/Class menu. If you can't upload patches to the liftoff project, you can put them under the jython project instead. I have commit rights to liftoff and will be able to commit them. regards, finn |
|
From: Brad C. <bk...@mu...> - 2001-03-27 14:24:19
|
On 27 Mar 2001, at 10:45, Finn Bock wrote: > [Moved to jython-dev and cc'ed: liftoff-users] Thanks, I don't think I'm on the jython-dev list however. > >To install, the .class needs to be unzipped somewhere (I suggest sys:Jython) > > By default the installer picks the user.home property. If that property > is initialized by the netware JVM, we should just use that. There isn't a user.. see next comment > >1. Add jython.jar to classpath by appending a line like this to the file sys:etc/java.cfg > > > >CLASSPATH=$CLASSPATH;sys:Jython/jython.jar > > > >(substitute the correct path) > > I don't yet have a wellformed opinion about this, but I would prefer if > the installation set the classpath in the script files if at all > possible. Not only does that match windows and unix behavior, it also > avoids a lot of problems with proper access rights to sys:etc (I guess). When operating at the NetWare system console, you *are* God. There is no security and you have full and complete rights to the entire system. There isn't any concept of "user" either. I think classpath could be specified in the .ncf files, but the ultimate goal is to be able to use Jython in servlets and other java programs without having to include the full Jython distribution into every servlet .jar file. There's no way to easily modify all the other programs to include Jython.jar in their command line, so it seems to me that Jython.jar should be a system-wide .jar file for this environment. I'm certainly open to other suggestions! Brad Clements, bk...@mu... (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements |
|
From: <bc...@wo...> - 2001-03-27 15:29:12
|
On Tue, 27 Mar 2001 09:33:45 -0500, you wrote: >> [Moved to jython-dev and cc'ed: liftoff-users] > >Thanks, I don't think I'm on the jython-dev list however. The list is open for admission all the time. >> >To install, the .class needs to be unzipped somewhere (I suggest sys:Jython) >> >> By default the installer picks the user.home property. If that property >> is initialized by the netware JVM, we should just use that. > >There isn't a user.. see next comment Does that mean the "user.home" property is not set? If it is set, what value does it have? >> >1. Add jython.jar to classpath by appending a line like this to the file sys:etc/java.cfg >> > >> >CLASSPATH=$CLASSPATH;sys:Jython/jython.jar >> > >> >(substitute the correct path) >> >> I don't yet have a wellformed opinion about this, but I would prefer if >> the installation set the classpath in the script files if at all >> possible. Not only does that match windows and unix behavior, it also >> avoids a lot of problems with proper access rights to sys:etc (I guess). > >When operating at the NetWare system console, you *are* God. There is no security >and you have full and complete rights to the entire system. There isn't any concept of >"user" either. > >I think classpath could be specified in the .ncf files, but the ultimate goal is to be able to >use Jython in servlets and other java programs without having to include the full Jython >distribution into every servlet .jar file. I agree with this goal. >There's no way to easily modify all the other programs to include Jython.jar in their >command line, so it seems to me that Jython.jar should be a system-wide .jar file for >this environment. I agree with this as well. The question is whether the installer should try and modify sys:etc/java.cfg. I would rather leave that as a manual option that the admin can perform herself. It is somewhat similar to the PATH envvar on Windows and Unix. After a jython installation, you will have to edit the PATH yourself. IMO this is a good feature of the installer. It shouldn't try to edit autoexec.bat or ~/.login or the PATH entry in the windows registry. Keeping all changes highly localized gives the user a good and secure feeling that she still owns the computer. regards, finn |
|
From: Brad C. <bk...@mu...> - 2001-03-27 15:56:59
|
On 27 Mar 2001, at 15:25, Finn Bock wrote: > >There isn't a user.. see next comment > > Does that mean the "user.home" property is not set? If it is set, what > value does it have? user.home = "SYS:" user.name = "PIT" (the file server's name) user.dir = "SYS:" > It is somewhat similar to the PATH envvar on Windows and Unix. After a > jython installation, you will have to edit the PATH yourself. IMO this > is a good feature of the installer. It shouldn't try to edit > autoexec.bat or ~/.login or the PATH entry in the windows registry. > > Keeping all changes highly localized gives the user a good and secure > feeling that she still owns the computer. Okay, good idea. How about I just create a file perhaps called "appendjava.cfg" in the installation directory and tell folks to alter their existing java.cfg file to "look like" that file. with the usual cautionary notes to not duplicate .. etc. Brad Clements, bk...@mu... (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements |
|
From: <bc...@wo...> - 2001-03-27 19:41:09
|
[Brad Clements] >> >There isn't a user.. see next comment >> >> Does that mean the "user.home" property is not set? If it is set, what >> value does it have? > > >user.home = "SYS:" Is that a valid directory? If it is, I suppose that SYS:jython-2.0 would be a acceptable default installation destination. >> It is somewhat similar to the PATH envvar on Windows and Unix. After a >> jython installation, you will have to edit the PATH yourself. IMO this >> is a good feature of the installer. It shouldn't try to edit >> autoexec.bat or ~/.login or the PATH entry in the windows registry. >> >> Keeping all changes highly localized gives the user a good and secure >> feeling that she still owns the computer. > >Okay, good idea. How about I just create a file perhaps called "appendjava.cfg" in the >installation directory and tell folks to alter their existing java.cfg file to "look like" that file. >with the usual cautionary notes to not duplicate .. etc. Sounds good to me. regards, finn |