License Question?
Locked
123456
123456
 
|
Bill,
the current Quick Start Guide does not recommend it; it merely states it as a deprecated option. You left out the footnote that states why it is deprecated. best regards, René. On 2012-09-12 17:46, Bill Fenlason wrote: > On 9/11/2012 6:05 PM, Tom Maynard wrote: > >> On 9/11/2012 3:10 PM, Kermit Kiser wrote: >> >>> They don't mention the other problems it may cause >> >> They do state -- somewhere else, and I'm not inspired to chase it >> down at the moment -- that it rears its ugly head when you have more >> than one version of Java installed. MFC by his own admission has >> four. Oh, the humanity! >> >> There was a time, around/about Java 1.2 or 1.3, when piling junk >> into the ext directory was endorsed, if not officially recommended. >> Given the amount of paperwork on his desk that Thomas is always >> calling to our attention, and guessing at its probable age and >> currency, I'm inclined to think that his reference documents are at >> least somewhat out of date. >> >> I would be delighted to be proven wrong. >> >> Tom. > > As for the recommendations regarding installation, here is some > hopefully accurate information. > The underlining and bold text (if your email reader supports it) is > mine. > > THE NETREXX USER'S GUIDE, VERSION 2.00, DATED 31ST AUGUST 2000 > contained the following: > > Installing the NetRexx translator > > The NetRexx package includes the NetRexx translator - a Java > application which can be used for compiling, interpreting, or > syntax-checking NetRexx programs. The procedure for installation is > briefly as follows (full details are given later): > > 1. Make the translator visible to the Java Virtual Machine (JVM): > > * IF YOU ARE RUNNING JAVA 1.2 OR LATER, COPY THE FILE > NETREXXLIBNETREXXC.JAR TO THE JRELIBEXT DIRECTORY IN THE JAVA > INSTALLATION TREE. THE JVM WILL AUTOMATICALLY FIND IT THERE AND MAKE > IT AVAILABLE. > > * If you are using an earlier Java version (1.1.2 through 1.1.8) > instead add the full path and filename of the NetRexxlibNetRexxC.jar > to the CLASSPATH environment variable for your operating system. > > Note: if you have a NetRexxC.zip in your CLASSPATH from an earlier > version of Rexx, remove it (NetRexxC.jar replaces NetRexxC.zip). > > 2. Copy all the files in the NetRexxbin directory to a directory in > your PATH (PERHAPS THE BIN DIRECTORY IN THE JAVA INSTALLATION TREE). > This is not essential, but makes shorthand scripts and a test case > available. > > 3. If you are running Java 1.2 or later, make the file libtools.jar > (which contains the javac compiler) in the Java tree visible to the > JVM. You can do this either by adding its path and filename to the > CLASSPATH environment variable, or by moving it to the jrelibext > directory in the Java tree. > > > > ------------------------------------------------------------------------------------------------- > > This above document is certainly out of date, However, THE > DISTRIBUTED NETREXX 3.01 RELEASE ZIP FILE contains the following in > the NetRexx 3.01 ReleasedocumentsNetRexx Quickstart Guide 3.01.pdf > file: > > The NetRexx 3.01 Quickstart Guide Version 3.01 August 23, 2012 > > 2.2 Installing the NetRexx Translator > > The NetRexx package includes the NetRexx translator - a Java > application which can be used for compiling, interpreting, or > syntax-checking NetRexx programs. The procedure > for installation is as follows: > > 1. Make the translator visible to the Java Virtual Machine (JVM) - > either: > .Add the full path and filename of the NetRexx/lib/NetRexxC.jar to > the CLASSPATH environment variable for your operating system. > > Note: if you have a Net-RexxC.zip in your CLASSPATH from an earlier > version of NetRexx, remove it (.NetRexxC.jar replaces NetRexxC.zip). > > OR (DEPRECATED): COPY THE FILE NETREXX/LIB/NETREXXC.JAR TO THE > JRE/LIB/EXT DIRECTORY IN THE JAVA INSTALLATION TREE. THE JVM WILL > AUTOMATICALLY FIND IT THERE AND MAKE IT AVAILABLE. > > 2. Copy all the files in the NetRexx/bin directory to a directory in > your PATH (PERHAPS THE /BIN DIRECTORY IN THE JAVA INSTALLATION TREE). > This is not essential, but makes shorthand scripts and a test case > available. > > 3. Make the file [...]/lib/tools.jar (which contains the javac > compiler) in the Java tree visible to the JVM. You can do this either > by adding its path and filename to the CLASSPATH environment > variable, > OR BY MOVING IT TO THE JRE/LIB/EXT DIRECTORY IN THE JAVA TREE. This > file sometime goes under different names, that will be mentioned in > the platform-specific appendices. > > > > ------------------------------------------------------------------------------------------------- > > So to be clear about this - the current download of NetRexx > recommends the use of the Java installation tree as a potential > target > for NetRexx files. > > Bill _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
Hi George,
I was thinking more along the lines of providing a platform-correct environment setting example, and pre-generated scripts that contain the equivalent of -cp %classpath%;path-to-NetRexxC.jar;path-to-tools.jar or a -Dnrx.compiler=ecj when the installer could not locate tools.jar. I am against modifying other persons environments even through installers that might be allowed to do that. I even have a strict stance on scripting dependencies that would prohibit setting global environments in production environments. I have seen enough installers break systems to not ever want to automatically modify one myself. When developing, I have exactly the same approach - for every application there is a top level script, that I execute by hand in a command shell. That would set the environment for the scope of the project. best regards, René. On 2012-09-12 16:29, George Hovey wrote: > Rene, > Nice. My original question was basically "are we missing the forest > for the trees regarding installation" and I find the ensuing > discussion both enlightening and reassuring. > > One thing caught my attention: > > "Adding elements to path and classpath is also implied... > > Is there some thought of modifying the environment? I am profoundly > suspicious of this (I worked at a place where this was done > promiscuously with unpleasant effects). > I develop from command windows under Windows 7. My practice is to > add exactly one element to the system Path: a directory containing a > "boot" script (DEV.CMD) and essential utilities. DEV.CMD sets up my > complex development environment (e.g., adds many elements to path). > This is a purely local environment that affects only the command > prompt from which it is run. A key feature is that the script > documents the date and reason for adding each element to Path. > > In this connection, some installs I work with are kind enough to > place > necessary paths and variables in a file to be handled as the user > sees > fit rather than silently attacking the environment. > > On Wed, Sep 12, 2012 at 9:03 AM, rvjansen <[hidden email] [3]> > wrote: > >> Bill, >> >> comments inline. >> >> On 2012-09-11 16:27, Bill Fenlason wrote: >> >>> On 9/11/2012 8:57 AM, rvjansen wrote: >>> >>>> this is not a good solution, for several reasons outlined >>>> earlier, and in extenso in the NetRexx User's Guide. The fact of >>>> the matter is that serious java development is impossible >>>> without knowing how to maintain a classpath. A couple of points: >>> >>> First, if we are at all targeting the beginning programmer and >>> non-java programmers, wouldn't it make sense that we should be >>> striving to hide the mysteries of the class path from them? >> I tend to disagree; you cannot really master any runtime if you >> don't know where it finds things; there are some simple rules one >> needs to know that will enable everyone to develop all kinds of >> programs in the Java universe; otherwise people would be limited in >> their ability and NetRexx will be a disappointment or seen as >> something to do simple scripting or programming in. To run in a J2EE >> container, make a Swing or JavaFX program, interact with Javascript >> etc etc will all require the same simple knowledge of classpath. >> >>> Second, I continue to believe that all the classpath, tools jar >>> and >>> compiler location problems are still an installation issue, and >>> that >>> the proper approach for a solution is to develop a set of web >>> based, >>> single click installers for each operating system (windows, OSX >>> and >>> linux, and maybe android in the future). >> >> Web based (as in Java) is not very dependable, and insecure, even >> when signed jars are used, to be attempted on its own. If it can be >> a spinoff of another installer, great, and we will have to weigh the >> risks or suffer the support questions caused by it. >> >> A universal installer could be developed with its first step being >> to >> determine the >> >>> oment. >>> >>> I truly do n >> why there is not universal agreement to >> this, since every other position is equivalent to "we want to make >> the >> installation of NetRexx m >> >>> ote> Not true. Adding elements to path and classpath is also >>> implied by jRuby, Jython, Groovy, Scala etc. installations. Some >>> use a singly anchored environment variable with relative paths for >>> both and suffer the consequences if something is moved by the user >>> or th >> JVM. Compared to programming, setting path and classpath is not that >> difficult. Path is not necessary, only if you want to use a script >> to invoke a compile. But you should understand path for running any >> script or executable. I don't have to explain to you where not >> understanding path for dll's leads to in Windows. >> >> The installation troubles that some have, are result of historical >> developments - nobody I know asked Sun to split JDK and SDK or to >> repackage the compiler class and move it off the (class) searchpath. >> Nobody I know asked Sun to have a different mental model for >> classpath than for path (it did in the very beginning - entire paths >> as elemets of classpath are only to be specified since the >> introduction of the Java archive, instead of making recursive >> directory/archive searches). This is reality and not part of our >> opinions or agreements. >> >> If there are any other major and popular programs which require the >> equivalent of what NetRexx does for installation, I would like to >> know >> what they are. Why should installing NetRexx be more difficult >> than >> installing Java? >> >> jRuby, Jython, Groovy, Scala etc. I think you are referring to >> another kind of program here, not our immediate langu >> >>> mes I had to help people who were lost in NetBeans, Eclipse, Idea, >>> Rational etc. to get their dll and/or classpaths back while using >>> one of our competitors. All these apps have simple installers; but >>> now try to exchange an xslt processor for your enterpr >> ep running after an admin does a small security change. >> >> Unfortunately I do not have the time or expertise to develop these >> installers or I would do so. >> >> Bill >> >> PS - talk about dead horses,,, :) >> >> The reality is that this will keep coming back as long as people >> install in the ext directory, switch java versions, or move stuff >> around, or forget to change the contents of a -cp switch in a >> script. Reality is also that we get it to work for most if not all >> people, and that t >> >>> . >>> >>> best regards, >>> >>> René. >>> >>> _______________________________________________ >>> Ibm >> ing list >> [hidden email] [1] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [2] _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by rvjansen
Rene, my conclusion was:
"So to be clear about this - the current download of NetRexx recommends the use of the Java installation tree as a potential target for NetRexx files." (Highlight added). Bullet point 2 clearly does this as well as the deprecated option in point 1. 2. Copy all the files in the NetRexx/bin directory to a directory in your PATH (PERHAPS THE /BIN DIRECTORY IN THE JAVA INSTALLATION TREE). This is not essential, but makes shorthand scripts and a test case available. Bullet 3 suggests moving the tools jar to the runtime directory: 3. Make the file [...]/lib/tools.jar (which contains the javac compiler) in the Java tree visible to the JVM. You can do this either by adding its path and filename to the CLASSPATH environment variable, OR BY MOVING IT TO THE JRE/LIB/EXT DIRECTORY IN THE JAVA TREE. This file sometime goes under different names, that will be mentioned in the platform-specific appendices. I should have included the foot note related to the deprecated option. To be complete, here is the foot note: 11 This has serious drawbacks, however: This breaks NetRexx applications running in custom class loader environments such as jEdit and NetRexxScript, as well as some JSP containers. As soon as the Java version is updated, NetRexx applications may mysteriously – due to the now obsolete path - fail. Running multiple versions of Java and NetRexx for testing purposes will become very hard when this way of installing is chosen. I believe my conclusion still stands. Bill On 9/12/2012 11:56 AM, rvjansen wrote:
Bill, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
In reply to this post by billfen
On 9/12/2012 10:46 AM, Bill Fenlason wrote:
> So to be clear about this - the current download of NetRexx recommends > the use of the Java installation tree as a potential target for > NetRexx files. I personally disagree with that recommendation, and have never implemented it myself (probably because I never read the documentation that carefully!). And, at least as it stands right now, the NetRexx installer doesn't dink with other programs' directory trees. However, NetRexx development is a team effort and there is no 'I' in 'team' (as the groupthink saying goes). And, the NetRexx installer is far from complete (where 'complete' means 'ready for the outside world to see'). Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
In reply to this post by rvjansen
On 9/12/2012 11:05 AM, rvjansen wrote:
> When developing, I have exactly the same approach - for every > application there is a top level script, that I execute by hand in a > command shell. That would set the environment for the scope of the > project. Golly. It's rather surprising that so many of us have adopted nearly identical solutions to these problems. It's probably because we have all been burned (or known others who were burned) by the alternatives. I do precisely the same things, myself. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I thought I was just dumb for having so much trouble with it. Now it seems it was because there is/was so much *conflicting* documentation. This was my eventual solution: I run my "startme.bat" when I open a term on windows 7: I guess it could be in autoexec.bat in my $HOME: @echo on prompt $p$+$S$S$d$s$t$H$H$H$H$H$H$_$s$g$s title this window has been set up with a path and classpath set PATH=.;H:\keklein\;C:\Users\keklein\REXX\NetRexx\nr301\bin;C:\Users\KEKLEIN\vim\;C:\Program Files\IBM\Personal Communications\;C:\Program Files\IBM\Trace Facility\;C:\Program Files\Java\jdk1.7.0_05\bin;C:\Program Files\QuickTime\QTSystem\;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\System32\Wbem;H:\keklein\My Documents\apache-ant-1.8.2\bin set CLASSPATH=.;C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\NetRexxC.jar;C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\ecj-4.2.jar;C:\Program Files\Java\jdk1.7.0_05\lib\tools.jar;C:\Program Files\Java\jre6\lib\ext\QTJava.zip set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_05\bin set HOME=H: set VIMRC=H: set VIMRUNTIME=C:\Users\KEKLEIN\vim set ANT_HOME=H:\keklein\My Documents\apache-ant-1.8.2 doskey /listsize=999 doskey /macrofile=macinit @echo Initialization settings are all set up. Then I run this .bat file to be able to quickly see that everything is where I think it isL echo off :: @echo. %0 :: type %0 set holding.file.tmp=%random%.%0.tmp @echo. %path% > %holding.file.tmp% @echo. @echo. "This is a nice list of your path at the moment:" @echo. for /F "usebackq eol=^ tokens=1-26* delims=;" %%a in (`type %holding.file.tmp%`) do ( if NOT "%%a"=="" echo. %%a if NOT "%%b"=="" echo. %%b if NOT "%%c"=="" echo. %%c if NOT "%%d"=="" echo. %%d if NOT "%%e"=="" echo. %%e if NOT "%%f"=="" echo. %%f if NOT "%%g"=="" echo. %%g if NOT "%%h"=="" echo. %%h if NOT "%%i"=="" echo. %%i if NOT "%%j"=="" echo. %%j if NOT "%%k"=="" echo. %%k if NOT "%%l"=="" echo. %%l if NOT "%%m"=="" echo. %%m if NOT "%%n"=="" echo. %%n if NOT "%%o"=="" echo. %%o if NOT "%%p"=="" echo. %%p if NOT "%%q"=="" echo. %%q if NOT "%%r"=="" echo. %%r if NOT "%%s"=="" echo. %%s if NOT "%%t"=="" echo. %%t if NOT "%%u"=="" echo. %%u if NOT "%%v"=="" echo. %%v if NOT "%%w"=="" echo. %%w if NOT "%%x"=="" echo. %%x if NOT "%%y"=="" echo. %%y if NOT "%%z"=="" echo. %%z ) @echo. %classpath% > %holding.file.tmp% @echo. @echo. "This is a nice list of your classpath at the moment:" @echo. for /F "usebackq eol=^ tokens=1-26* delims=;" %%a in (`type %holding.file.tmp%`) do ( if NOT "%%a"=="" echo. %%a if NOT "%%b"=="" echo. %%b if NOT "%%c"=="" echo. %%c if NOT "%%d"=="" echo. %%d if NOT "%%e"=="" echo. %%e if NOT "%%f"=="" echo. %%f if NOT "%%g"=="" echo. %%g if NOT "%%h"=="" echo. %%h if NOT "%%i"=="" echo. %%i if NOT "%%j"=="" echo. %%j if NOT "%%k"=="" echo. %%k if NOT "%%l"=="" echo. %%l if NOT "%%m"=="" echo. %%m if NOT "%%n"=="" echo. %%n if NOT "%%o"=="" echo. %%o if NOT "%%p"=="" echo. %%p if NOT "%%q"=="" echo. %%q if NOT "%%r"=="" echo. %%r if NOT "%%s"=="" echo. %%s if NOT "%%t"=="" echo. %%t if NOT "%%u"=="" echo. %%u if NOT "%%v"=="" echo. %%v if NOT "%%w"=="" echo. %%w if NOT "%%x"=="" echo. %%x if NOT "%%y"=="" echo. %%y if NOT "%%z"=="" echo. %%z ) @echo. @echo. Done. @echo. del %holding.file.tmp% This is the output from startme.bat: H:\keklein Wed 09/12/2012 13:43:00.06 > prompt $p$+$S$S$d$s$t$H$H$H$H$H$H$_$s$g$s H:\keklein Wed 09/12/2012 13:43:00.06 > title this window has been set up with a path and classpath H:\keklein Wed 09/12/2012 13:43:00.06 > set PATH=.;H:\keklein\;C:\Users\keklein\REXX\NetRexx\nr301\bin;C:\Users\KEKLEIN\vim\;C:\Program Files\IBM\Personal Communications\;C:\Program Files\IBM\Trace Facility\;C:\Program Files\Java\jdk1.7.0_05\bin;C:\Program Files\QuickTime\QTSystem\;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\System32\Wbem;H:\keklein\My Documents\apache-ant-1.8.2\bin H:\keklein Wed 09/12/2012 13:43:00.06 > set CLASSPATH=.;C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\NetRexxC.jar;C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\ecj-4.2.jar;C:\Program Files\Java\jdk1.7.0_05\lib\tools.jar;C:\Program Files\Java\jre6\lib\ext\QTJava.zip H:\keklein Wed 09/12/2012 13:43:00.06 > set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_05\bin H:\keklein Wed 09/12/2012 13:43:00.06 > set HOME=H: H:\keklein Wed 09/12/2012 13:43:00.06 > set VIMRC=H: H:\keklein Wed 09/12/2012 13:43:00.06 > set VIMRUNTIME=C:\Users\KEKLEIN\vim H:\keklein Wed 09/12/2012 13:43:00.06 > set ANT_HOME=H:\keklein\My Documents\apache-ant-1.8.2 H:\keklein Wed 09/12/2012 13:43:00.06 > doskey /listsize=999 H:\keklein Wed 09/12/2012 13:43:00.11 > doskey /macrofile=macinit Initialization settings are all set up. This is the output from listpath.bat: H:\keklein Wed 09/12/2012 13:43:10.97 > echo off "This is a nice list of your path at the moment:" . H:\keklein\ C:\Users\keklein\REXX\NetRexx\nr301\bin C:\Users\KEKLEIN\vim\ C:\Program Files\IBM\Personal Communications\ C:\Program Files\IBM\Trace Facility\ C:\Program Files\Java\jdk1.7.0_05\bin C:\Program Files\QuickTime\QTSystem\ C:\WINDOWS C:\WINDOWS\system32 C:\WINDOWS\System32\Wbem H:\keklein\My Documents\apache-ant-1.8.2\bin "This is a nice list of your classpath at the moment:" . C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\NetRexxC.jar C:\Users\KEKLEIN\REXX\NetRexx\nr301\lib\ecj-4.2.jar C:\Program Files\Java\jdk1.7.0_05\lib\tools.jar C:\Program Files\Java\jre6\lib\ext\QTJava.zip Done.
On 9/12/2012 11:05 AM, rvjansen wrote: > When developing, I have exactly the same approach - for every > application there is a top level script, that I execute by hand in a > command shell. That would set the environment for the scope of the > project. Golly. It's rather surprising that so many of us have adopted nearly identical solutions to these problems. It's probably because we have all been burned (or known others who were burned) by the alternatives. I do precisely the same things, myself. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
No, really, deprecating is not recommending. The ext dir is a possible installation location, and undeniably works in some cases. It is deprecated for mentioned reasons. Us being an open source community, I will replace the text immediately by something that has more clarity but is still correct if someone writes this up. It is a potential target. It is not recommended as a potential taregt; it is a shortcut solution with dire drawbacks. Those are mentioned, here as well as in the Oracle docs. And in different wording, suggested to be a less desirable solution for most apps in the IBM J9 documentation. And documented in numerous bugs all over the net. This is not about being right, it is about facts. Without discussion this works for some people for some of the time. It is not the best solution, this is why it is mentioned and deprecated. It is not to be left out. We have explained why in the docs (as addition to the older doc that just mentions it). The classloader issues in NetRexx will be fixed. It is like ordering a cappucino in the US. In Europe, the Italians invented cappucino some centuries ago, and if you ask for one you'll get one. In the US, you will have to answer questions about decaf, skimmed, half skimmed or low fat milk, sweetener, cacao or cinnamon. There seems to be no way back if choice is introduced. If I would leave out the ext directory from the Quick Start Guide, every month someone will suggest it as the best solution. By the way, sometimes you will get, in France or Austria, a cappucino with whipped cream instead of milk; we call that Café Vienna. Best regards, René. On 12 sep. 2012, at 18:18, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Rene,
Bullet 2 and bullet 3 under "Installing the NetRexx translator" are NOT deprecated. In this note I am specifically addressing Bullet 2, and NOT Bullet 1 (the placement of the NetRexxC jar into the ext directory) or Bullet 3 (the moving of the tools jar to the JRE directory). How can you say that: "Copy all the files in the NetRexx/bin directory to a directory in your PATH (PERHAPS THE /BIN DIRECTORY IN THE JAVA INSTALLATION TREE)." is not a recommendation? Generally, that type of language is taken as such. Please explain why you think that is that not consistent with my conclusion? "So to be clear about this - the current download of NetRexx recommends the use of the Java installation tree as a potential target for NetRexx files." Bill PS while your comparisons to cappuccino are entertaining, I don't think they add substance to the analysis of this situation. On 9/12/2012 3:23 PM, René Jansen
wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Bill,
The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century, but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that. Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)? best regards, René. On 12 sep. 2012, at 22:08, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Kermit Kiser
Kermit, will read in detail later, will reply later, did file under my
Folder: NetRexx TO REMEMBER. Will now *definitely* seek my printed folders (and there are a lot of them) for the ORIGINAL URL *I did use* to make *my NetRexx Applications* ***working*** without *any need* to use the +classpath* +ANYMORE+ ... Years ago, I must admit, but: Since then: All of my (many) NetRexx .jar(s) do work without any problems, for me, and my customers, as well. QUOD DIXI, DIXI! (Latin: What I did say, I did say) Thomas. ======================================================================================= Am 11.09.2012 22:10, schrieb Kermit Kiser: > Thomas, you are making *me* tired. > > I understand that you have found a procedure that works for your stuff > and that you don't care if it breaks things for everyone else. You > probably won't listen to my advice but for the benefit of others I > will try. > > The very first entry when you search Google for "Java extensions > directory" is this official Oracle page: > > http://docs.oracle.com/javase/tutorial/ext/basics/install.html > > It provides the following warnings about using the lib\ext directory > near the beginning: > > ------------------------------------------------------------------------------------------------------------------------- > > Since installed extensions extend the platform's core API, use them > judiciously. They are rarely appropriate for interfaces used by a > single, or small set of applications. > > Furthermore, since the symbols defined by installed extensions will be > visible in all Java processes, care should be taken to ensure that all > visible symbols follow the appropriate "reverse domain name" and > "class hierarchy" conventions. For example, com.mycompany.MyClass. > > ------------------------------------------------------------------------------------------------------------------------- > > > They don't mention the other problems it may cause, such as when you > run a program that requires a newer version of the NetRexx library > which it includes but it cannot find that library because you have an > older version installed in lib\ext. Or the problems encountered if > your program needs to access classes from the application classpath > but cannot find them because you copied it into the lib\ext directory. > I am sure others can list other problems. > > So why don't you stop trying to tell us that a "Java Standard" > specifies that everything be installed in lib\ext when even Oracle > warns that it is not appropriate for most cases. > > -- Kermit > > > On 9/11/2012 7:06 AM, Thomas Schneider wrote: >> Gentlepeople, >> now *I* am getting tired ... :-( >> >> I will now search in my folders for the *original Java Document* >> specifying that any additional software >> *should be installed* in the ...\lib\ext directory. >> >> When found, I will publish the URL for all of you! >> >> It is a *specified* ***Java Standard***, Gentlewoman and Gentlemen! >> >> Full Stop. >> Thomas. >> ============================================================== >> Am 11.09.2012 14:57, schrieb rvjansen: >>> Thomas, >>> >>> this is not a good solution, for several reasons outlined earlier, >>> and in extenso in the NetRexx User's Guide. The fact of the matter >>> is that serious java development is impossible without knowing how >>> to maintain a classpath. The code depency issues in your own work >>> are even caused by depending on a stale copy in the ext lib. I wish >>> you would stop suggesting this to people on the list. In the light >>> of Kermit's recent research, moving the tools.jar library is even >>> worse than copying it. >>> >>> best regards, >>> >>> René. >>> >>> >>> >>> On 2012-09-11 14:45, Thomas Schneider wrote: >>>> As I already did advise, sooo many times: >>>> >>>> The sequence of action has to be: >>>> >>>> 1.) Copy (*or*, better, *move* ) tools.jar to ...libext after >>>> download of any new Java developers kit (the proper ones, of course) >>>> 2.) Copy (*or* better, *move* ) any and all NetRexx Tools, including >>>> the NetRexxC.jar in question >>>> to the same ...libext directory! To *all* those, when you do have >>>> multiple Java jdk's installed. >>>> >>>> Then, and *only then*, you will need *no classpath modifications *at >>>> all*. >>>> >>>> *And*, Kermit, your can simply *quote me by Name* (Thomas Schneider)* >>>> for this recommandation. >>>> >>>> I would prefer this to *some NetRexxers* ;-) >>>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > -- Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by rvjansen
Short question Rene, and all:
*Why is this* *** ooRexx related issue *** discussed here on ibm-netrexx ?? My impression has always been, that *ooRexx* is owned and maintained by the RexxLA list, and ibm-netrexx does *concentrate on NetRexx* ... ;-) Any changes in the usage of those 2 lists I'm *not aware of* ??? Thomas. =============================================================================== Am 12.09.2012 13:59, schrieb rvjansen: > George, > > in the first place, Alan is right, and MacOSX is, and has been from a > number of years, the easiest platform to build ooRexx on - all tools > provided by Apple, and one 'svn update && sudo make install' does it. > > The reason there are no OSX packages is indeed one of priorities, and > it was NetRexx that became the priority. I did provide the OSX > packages previously but the work for NetRexx took over, and > unfortunately the packages landed on the backburner, also because I > was always up to date with my own ooRexx build, and the Apple package > builder is a time robbing point-and-click GUI thing - I was forever > planning to make it a batch process but never could find a stable API > for it. Nor a stable GUI, by the way. (It kept 'improving' so I could > never find the same buttons in the same place). > > Fortunately, Bruce Skelly has now taken over the production of the OS > X installer package; 32 and 64 bit oorexx 4.1.2 versions have recently > been made available for testing and will be generally available soon. > > best regards, > > René. > > > On 2012-09-11 19:10, Alan Sampson wrote: >> On 11 September 2012 09:37, Bill Fenlason <[hidden email] [1]> >> wrote: >> >>> On 9/11/2012 12:03 PM, George Hovey wrote: >>> >>> It is interesting that the last oorexx OSX download was for >>> release 3.2 ( current is 4.1.1) so I suspect the OSX users are a >>> possibly small minority. Indeed, apparently AIX is a higher >>> priority, since a 4.1.0 version is provided. >> >> Yes, I'm disappointed that there's been no new installation package >> for OS X since 3.2. If it weren't for Rony's excellent efforts with >> BSF4REXX which delivers ooRexx 4.1.1 Mac users would be completely cut >> off from newer versions of ooRexx. I'd like to see that change too. >> >> On the up side with Mac OS X though, as it's basically BSD when you >> get to a terminal window it has a very similar set of tools and >> conventions to Linux so installing NetRexx on OS X has never bee much >> of a challenge. >> >> Alan. >> -- >> Can't tweet, won't tweet! >> >> >> Links: >> ------ >> [1] mailto:[hidden email] > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > -- Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
Thomas,
it was an answer to a remark from George and on-topic as far as it concerned installers and the fact that the one for ooRexx for MacOSX was lagging because of my shifted attention to NetRexx. Another subject that might be on-topic on both lists is bsf4ooRexx, which might touch Rexx and Java in the form of NetRexx. Notice that there was no cross-posting. best regards, René. On 12 sep. 2012, at 22:56, Thomas Schneider <[hidden email]> wrote: > Short question Rene, and all: > > *Why is this* > > *** ooRexx related issue *** > > discussed here on ibm-netrexx ?? > > My impression has always been, that *ooRexx* is owned and maintained by the RexxLA list, and ibm-netrexx > does *concentrate on NetRexx* ... ;-) > > Any changes in the usage of those 2 lists I'm *not aware of* ??? > Thomas. > =============================================================================== > Am 12.09.2012 13:59, schrieb rvjansen: >> George, >> >> in the first place, Alan is right, and MacOSX is, and has been from a number of years, the easiest platform to build ooRexx on - all tools provided by Apple, and one 'svn update && sudo make install' does it. >> >> The reason there are no OSX packages is indeed one of priorities, and it was NetRexx that became the priority. I did provide the OSX packages previously but the work for NetRexx took over, and unfortunately the packages landed on the backburner, also because I was always up to date with my own ooRexx build, and the Apple package builder is a time robbing point-and-click GUI thing - I was forever planning to make it a batch process but never could find a stable API for it. Nor a stable GUI, by the way. (It kept 'improving' so I could never find the same buttons in the same place). >> >> Fortunately, Bruce Skelly has now taken over the production of the OS X installer package; 32 and 64 bit oorexx 4.1.2 versions have recently been made available for testing and will be generally available soon. >> >> best regards, >> >> René. >> >> >> On 2012-09-11 19:10, Alan Sampson wrote: >>> On 11 September 2012 09:37, Bill Fenlason <[hidden email] [1]> >>> wrote: >>> >>>> On 9/11/2012 12:03 PM, George Hovey wrote: >>>> >>>> It is interesting that the last oorexx OSX download was for >>>> release 3.2 ( current is 4.1.1) so I suspect the OSX users are a >>>> possibly small minority. Indeed, apparently AIX is a higher >>>> priority, since a 4.1.0 version is provided. >>> >>> Yes, I'm disappointed that there's been no new installation package >>> for OS X since 3.2. If it weren't for Rony's excellent efforts with >>> BSF4REXX which delivers ooRexx 4.1.1 Mac users would be completely cut >>> off from newer versions of ooRexx. I'd like to see that change too. >>> >>> On the up side with Mac OS X though, as it's basically BSD when you >>> get to a terminal window it has a very similar set of tools and >>> conventions to Linux so installing NetRexx on OS X has never bee much >>> of a challenge. >>> >>> Alan. >>> -- >>> Can't tweet, won't tweet! >>> >>> >>> Links: >>> ------ >>> [1] mailto:[hidden email] >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > > -- > Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Agreed, folks, ***NO PROBLEM FOR ME ***
As all of you do know, some years ago I have been punished to do CROSS-POSTS to both lists ... But, as you see, I'm following any and all news relating my business ... Cheers, Massa Thomas .... <grin> ============================================================================= Am 12.09.2012 23:06, schrieb René Jansen: > Thomas, > > it was an answer to a remark from George and on-topic as far as it concerned installers and the fact that the one for ooRexx for MacOSX was lagging because of my shifted attention to NetRexx. Another subject that might be on-topic on both lists is bsf4ooRexx, which might touch Rexx and Java in the form of NetRexx. Notice that there was no cross-posting. > > best regards, > > René. > > On 12 sep. 2012, at 22:56, Thomas Schneider <[hidden email]> wrote: > >> Short question Rene, and all: >> >> *Why is this* >> >> *** ooRexx related issue *** >> >> discussed here on ibm-netrexx ?? >> >> My impression has always been, that *ooRexx* is owned and maintained by the RexxLA list, and ibm-netrexx >> does *concentrate on NetRexx* ... ;-) >> >> Any changes in the usage of those 2 lists I'm *not aware of* ??? >> Thomas. >> =============================================================================== >> Am 12.09.2012 13:59, schrieb rvjansen: >>> George, >>> >>> in the first place, Alan is right, and MacOSX is, and has been from a number of years, the easiest platform to build ooRexx on - all tools provided by Apple, and one 'svn update && sudo make install' does it. >>> >>> The reason there are no OSX packages is indeed one of priorities, and it was NetRexx that became the priority. I did provide the OSX packages previously but the work for NetRexx took over, and unfortunately the packages landed on the backburner, also because I was always up to date with my own ooRexx build, and the Apple package builder is a time robbing point-and-click GUI thing - I was forever planning to make it a batch process but never could find a stable API for it. Nor a stable GUI, by the way. (It kept 'improving' so I could never find the same buttons in the same place). >>> >>> Fortunately, Bruce Skelly has now taken over the production of the OS X installer package; 32 and 64 bit oorexx 4.1.2 versions have recently been made available for testing and will be generally available soon. >>> >>> best regards, >>> >>> René. >>> >>> >>> On 2012-09-11 19:10, Alan Sampson wrote: >>>> On 11 September 2012 09:37, Bill Fenlason <[hidden email] [1]> >>>> wrote: >>>> >>>>> On 9/11/2012 12:03 PM, George Hovey wrote: >>>>> >>>>> It is interesting that the last oorexx OSX download was for >>>>> release 3.2 ( current is 4.1.1) so I suspect the OSX users are a >>>>> possibly small minority. Indeed, apparently AIX is a higher >>>>> priority, since a 4.1.0 version is provided. >>>> Yes, I'm disappointed that there's been no new installation package >>>> for OS X since 3.2. If it weren't for Rony's excellent efforts with >>>> BSF4REXX which delivers ooRexx 4.1.1 Mac users would be completely cut >>>> off from newer versions of ooRexx. I'd like to see that change too. >>>> >>>> On the up side with Mac OS X though, as it's basically BSD when you >>>> get to a terminal window it has a very similar set of tools and >>>> conventions to Linux so installing NetRexx on OS X has never bee much >>>> of a challenge. >>>> >>>> Alan. >>>> -- >>>> Can't tweet, won't tweet! >>>> >>>> >>>> Links: >>>> ------ >>>> [1] mailto:[hidden email] >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> >> -- >> Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030 Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by rvjansen
Rene,
I think that moving things into the Java directories should be discouraged totally or endorsed totally. In other words, either do it or don't do it. Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories. I think that is a bad idea. My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions. From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago. I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it. But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there. That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create? I would assume that when the installation process is finalized, nothing will be moved into the Java directories either. (With the possible exception of the NetRexxR runtime if specifically requested by the user). Bill PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK. In general, each application has a directory in \Program Files\. I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default. Other operating systems have their own conventions, and I believe that they should be followed as well. For windows systems, to do otherwise will certainly cause lots of grief. B. On 9/12/2012 4:37 PM, René Jansen
wrote:
Bill, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
On most linux distro's jars go in /usr/share/java/ ; program gets executed with a script in a bin/ directory ; the script contains java -jar yourjarname
On Wed, Sep 12, 2012 at 5:36 PM, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
And /usr/share/java has nothing to do with the java install.
On Wed, Sep 12, 2012 at 5:45 PM, Jason Martin <[hidden email]> wrote: On most linux distro's jars go in /usr/share/java/ ; program gets executed with a script in a bin/ directory ; the script contains java -jar yourjarname _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I don't have any problem with that - if it is a standard approach
across all of the various distros, then it should be followed.
My point is that the installation in each operating system should be such that it provides no surprises. Where are the Java installed files? On 9/12/2012 5:56 PM, Jason Martin
wrote:
And /usr/share/java has nothing to do with the java install. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
I agree that we should take out the "perhaps to the java/bin [...]" suggestion, as it might be any other directory already on the executables path. I think we should mention the extension directory (directories) but strongly discourage the use of it (them). Ruling out the Java tree in its entirety might overshoot the mark. VM had NetRexx in the Java tree. Your suggested location for Windows makes sense, but you might not be administrator on the machine and the OS partition might be safeguarded against your modification.Still, we will enable you to 'install' NetRexx. On Windows machines with IBM middleware and associated JVM the location might be entirely different.
One of the distinguishing treats of NetRexx is that it might be installed everywhere and just pointed to. So, in my view, the installer, on Windows, should look for a writeable C:\Program Files (although I am no fan of the space in that name) and fall back to a directory mentioned in the users home environment variable when that is writeable and 'program files' is not - and have an option in which the user can specify a drive and directory. The fact that we can be admin in an installer does not mean we have to if there is no underlying technical requirement. Being able to switch to admin might add extra complications - we have been swindled out of the money for a certificate for ooRexx already. (Thomas - this is not crossposting - it would be if the Rexxla or ooRexx lists are also in the to: field) If there is an option "install for all users" then it is a different issue and we might opt for more central locations- and drag in the certificate and registry requirements. I foresee spme package managers for Linux and Mac will need NetRexx added (with their own conventions) - debian, yum, fink, ports, brew - we can only follow those. These are different and sometimes conflicting; this will be a lot of work. I suggest we all adopt a piece and make it happen. best regards, René. On 12 sep. 2012, at 23:36, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
In reply to this post by billfen
Bill -
I agree that NetRexx items should never be placed in Java directories. But I have to disagree with your PS. "C:\Program Files" was Microsoft's most successful effort at screwing the world up. Especially for Java environments because of the arcane and contradictory rules about spaces in classpath depending on how it is specified. (The environment variable rules are different than the operand rules, etc.) Putting NetRexx in a reasonable directory with no spaces in it's path name will help to eliminate installation woes on Windows systems. I suggest "C:\NetRexx" which is what I personally use. -- Kermit On 9/12/2012 11:36 AM, Bill Fenlason
wrote:
Rene, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
I see machines with several releases of several brands of JVM on it every day - there is just no telling what you will meet. The location of the Java files is completely orthogonal to that of the NetRexx jar. The process context determines what is used. There can be no assumptions on this - not even that Oracle keeps locations stable. My windows VM's have IBM, Oracle and OpenJDK on it. And some research VM's. I would like to follow Kermit's suggestion of just a \NetRexx in the root of some disk - that space in 'Program Files' has cost the world economy a lot of money.
René. On 13 sep. 2012, at 00:05, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |