License Question?
Locked
123456
123456
 
|
Bill, *Agreed* ...
By the way, for my own Software, which is now all in NetRexx, I'm working on a GUI-based Installer for it, but work is still in progress. For sure, I will then deploy this Installer for General Use OPEN SOURCE to www.netrerxx.org. The architecture of my installer is, that it is *driven* by an external ordinary CSV-File containing the pieces of soft to be installed, their location, their dependencies, etc. It is, originally, designed for my own soft, but I think we might then use it for other Netrexx related Software pieces as well. Currently, I'm still busy in testing and, more cumbersome, *documenting* what I did the past years. Sorry, I'm only 1 human beeing (as all of you, as well). Trying to do my best, anyway, as always. Thomas. ================================================================================ Am 11.09.2012 16:27, schrieb Bill Fenlason: > 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? > > 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). > > A universal installer could be developed with its first step being to > determine the operating system, by asking if necessary. > > There are few if any potential NetRexx users who prefer any kind of > detailed cookbook installation procedure to an installation which is > performed in a similar fashion to all the other programs he installs. > For linux that may be apt, rpm or whatever, for windows it will be an > installer similar to all the other windows installers the user has > used, and for OSX it would be a process familiar to those users. > > I truly do not understand why there is not universal agreement to > this, since every other position is equivalent to "we want to make the > installation of NetRexx more difficult than necessary, and different > from what you are used to". > > 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? > > Unfortunately I do not have the time or expertise to develop these > installers or I would do so. > > Bill > > PS - talk about dead horses,,, :) > > _______________________________________________ > 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 Mike Cowlishaw
Mike,
If you google "download java compiler" or "download java jdk", the first link is to an appropriate page. Granted that a google of "download java" leads you to the runtime download, I would not agree that Oracle is keeping the download of the JDK difficult. The download site for the JDK provides detailed Installation Guides. e.g: http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installation-windows.html It is clear that the reason that downloading the runtime is the primary route is because there are huge! numbers of users of the runtime, and in comparison relatively few compiler users. When you download the Java runtime, there is a link entitled "Remove Older Versions". If your system has 4 runtimes, (and they are out of date) perhaps you could try that? It is reasonable for the older versions to not be removed automatically, since they may be required for other uses. (e.g. I have 1.5, 1.6, and 7 because I need them for testing.) Bill On 9/11/2012 12:16 PM, Mike Cowlishaw
wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by rvjansen
Hi Rene,
*why* can we not build a *new* NetRexxInstall.jar *only used for the Installation*, containing NetRexxC.jar and NetRexxR.jar in turn, as well as the proper Installer? ? This could be also named according to the *version*, e.g.: NetRexx-3.01.jar, NetRexx-3.02.jar, etc, with the proper META-INFO as provided in the JAR-Specification? As I think, this technique would also allow us to implement *incremental Updates* of any of the existing versions, done automatically by NetRexxC itself, by inspecting whether a *patch* (update) is available already on www.NetRexx.org, for instance. What do you (all) say ? Thomas. =================================================================================== Am 11.09.2012 14:50, schrieb rvjansen: > No, it is of great importance we get clarity about this behavior, for > most jvm implementations; we must find out which measures will help > most people. > > The compiler problem would be over if we delivered a NetRexxC.jar with > the compiler in it. It will grow with about a megabyte, but I am under > the impression that size constraints are most important to the runtime > package NetRexxR.jar. > > This will not fix the java.lang.Object.class not found issue, but that > is a problem that occurs with a very low frequency. > How do we think about an included compiler with a changed default in > 3.02? > > René. > > On 2012-09-11 14:15, [hidden email] wrote: >> KK: >> >> Not to beat a dead horse, but the netrexx compiler was finding the ecj >> compiler when I still had the netrexx compiler in the java ext >> directory. It was first deleted from there this morning. >> > > _______________________________________________ > 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
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/ > -- 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 billfen
On 11 September 2012 09:37, Bill Fenlason <[hidden email]> wrote: --
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! _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Alan
-- Needs more cowbell. |
|
|
In reply to this post by billfen
It appears to me that the NetRexx installer is fundamentally a
bootstrap problem: unless we want to write a custom machine-code routine for each OS (and nobody does) we need to have a common platform to examine the host environment in order to properly install the NetRexx package. The obvious "common platform" is Java, but until we know where it is, we can't execute a NetRexx program to find it. So the simple solution is to include a bootstrap Java compiler (and NetRexx jar) that provides just enough support, for just long enough, to ascertain the host environment. The ECJ fits that bill nicely. Once the Java detector routine has run, there are two possibilities: it found a working Java compiler, or it didn't. In case 1, the installer proceeds to hook NetRexx up to the existing JDK, and optionally deletes the ECJ. In case 2, the installer downloads and installs the latest JDK and hooks NetRexx to it. In both cases, the installer keeps track of every change that it made to the host environment, so that it can be restored upon uninstall or upgrade. That should cover the "Automatic Install" option. The "Custom Install" option will prompt for all the pieces and let the user make all the decisions. The novice user gets all the hand-holding of a one-click install. A user who wants/needs to know all the ingredients in the sausage can read the Users Guide and/or perform a "Custom Install". This sounds to me like more than a SMOP but not impossible. I'm sure I'm missing several salients points here, so let's hear them. -Chip- On 9/11/2012 12:37 Bill Fenlason said: > On 9/11/2012 12:03 PM, George Hovey wrote: >> >> One click installation certainly seems desirable, but is it really >> that easy? You mention the ease of Java installation, but Sun has >> vast resources. Take a look at ooRexx's downloads >> (http://www.oorexx.org/download.html). On the face of it, this looks >> like a massive effort. If so, how much will be left over for >> NetRexx development? > > On the contrary, I believe the effort should be substantially easier > than that required by oorexx. For example, they have two different > downloads for Windows, and since NetRexx does not contain any exe > files, (i.e. it is all Java) only one Windows download should be > sufficient. > > Since I know little about linux, I can't comment, but I suspect that a > single version of rpm and deb files might be sufficient. > > 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. > > After all, at a minimum, what does the installer have to do besides > putting the NetRexx jar in an appropriate place and insuring (by > setting the path, classpath, etc.) that it (and the related compiler) > are easily accessible? > >> I didn't fully understand the rationale for the bundling of the ecj >> compiler. Given that Java is such a trouble free installation, I >> don't see why we couldn't just say to new users "first install Java" >> and point them at Sun's page. Then we start from well defined >> initial conditions relatively painlessly. > > "first install Java" will lead a user down a path that only installs > the Java runtime. It should read "first install the Java SDK > (software development kit)". > >> Re Rene's point - if you think "serious Java development" is a >> significant end point of NetRexx (and it's evident not everyone >> does), Java issues can't be finessed. On numerous occasions we've >> seen new users get up to the point where they need some Java >> facility (dates, Swing) and run into a brick wall. Well intentioned >> sample program are just gobbledy-gook to such a user, and they're >> reduced to accepting them as magical incantations. Of course, they >> are in no position to modify or extend the examples. I would >> approach that by introducing NetRexx in two phases: 1) everything >> you can do without awareness of Java; 2) the rest. >> >> On Tue, Sep 11, 2012 at 10:27 AM, Bill Fenlason <[hidden email] >> <mailto:[hidden email]>> 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? >> >> 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). >> >> A universal installer could be developed with its first step >> being to determine the operating system, by asking if necessary. >> >> There are few if any potential NetRexx users who prefer any kind >> of detailed cookbook installation procedure to an installation >> which is performed in a similar fashion to all the other >> programs he installs. For linux that may be apt, rpm or >> whatever, for windows it will be an installer similar to all the >> other windows installers the user has used, and for OSX it would >> be a process familiar to those users. >> >> I truly do not understand why there is not universal agreement >> to this, since every other position is equivalent to "we want to >> make the installation of NetRexx more difficult than necessary, >> and different from what you are used to". >> >> 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? >> >> Unfortunately I do not have the time or expertise to develop >> these installers or I would do so. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I am so flattered that my frustration has spawned such an in depth discussion of this classpath confusion. Since it was ME having this problem over and over as I upgraded to a new Netrexx release or a new computer or onto other platforms (osX) let me add my 2 cents worth: If there were just one (1) EIN installation document with clear steps on how to set a classpath (and no misdirecton, Herr S!) then my confusion would have been minimized. The envirotest class was a great help. I would like to see it expanded to point out what is missing, mismatched or otherwise misunderstood. Make it a sanity check to debug a failing installation. "one-click" installations only lead to developers who don't understand what is going on under the covers. And much thanks for Kermit's patience is explaining to me how Java finds its compiler. Which is another example of how trying to make something "one click" and fix things for every situation, just muddies the waters. Kenneth Klein
It appears to me that the NetRexx installer is fundamentally a bootstrap problem: unless we want to write a custom machine-code routine for each OS (and nobody does) we need to have a common platform to examine the host environment in order to properly install the NetRexx package. The obvious "common platform" is Java, but until we know where it is, we can't execute a NetRexx program to find it. So the simple solution is to include a bootstrap Java compiler (and NetRexx jar) that provides just enough support, for just long enough, to ascertain the host environment. The ECJ fits that bill nicely. Once the Java detector routine has run, there are two possibilities: it found a working Java compiler, or it didn't. In case 1, the installer proceeds to hook NetRexx up to the existing JDK, and optionally deletes the ECJ. In case 2, the installer downloads and installs the latest JDK and hooks NetRexx to it. In both cases, the installer keeps track of every change that it made to the host environment, so that it can be restored upon uninstall or upgrade. That should cover the "Automatic Install" option. The "Custom Install" option will prompt for all the pieces and let the user make all the decisions. The novice user gets all the hand-holding of a one-click install. A user who wants/needs to know all the ingredients in the sausage can read the Users Guide and/or perform a "Custom Install". This sounds to me like more than a SMOP but not impossible. I'm sure I'm missing several salients points here, so let's hear them. -Chip- On 9/11/2012 12:37 Bill Fenlason said: > On 9/11/2012 12:03 PM, George Hovey wrote: >> >> One click installation certainly seems desirable, but is it really >> that easy? You mention the ease of Java installation, but Sun has >> vast resources. Take a look at ooRexx's downloads >> (http://www.oorexx.org/download.html). On the face of it, this looks >> like a massive effort. If so, how much will be left over for >> NetRexx development? > > On the contrary, I believe the effort should be substantially easier > than that required by oorexx. For example, they have two different > downloads for Windows, and since NetRexx does not contain any exe > files, (i.e. it is all Java) only one Windows download should be > sufficient. > > Since I know little about linux, I can't comment, but I suspect that a > single version of rpm and deb files might be sufficient. > > 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. > > After all, at a minimum, what does the installer have to do besides > putting the NetRexx jar in an appropriate place and insuring (by > setting the path, classpath, etc.) that it (and the related compiler) > are easily accessible? > >> I didn't fully understand the rationale for the bundling of the ecj >> compiler. Given that Java is such a trouble free installation, I >> don't see why we couldn't just say to new users "first install Java" >> and point them at Sun's page. Then we start from well defined >> initial conditions relatively painlessly. > > "first install Java" will lead a user down a path that only installs > the Java runtime. It should read "first install the Java SDK > (software development kit)". > >> Re Rene's point - if you think "serious Java development" is a >> significant end point of NetRexx (and it's evident not everyone >> does), Java issues can't be finessed. On numerous occasions we've >> seen new users get up to the point where they need some Java >> facility (dates, Swing) and run into a brick wall. Well intentioned >> sample program are just gobbledy-gook to such a user, and they're >> reduced to accepting them as magical incantations. Of course, they >> are in no position to modify or extend the examples. I would >> approach that by introducing NetRexx in two phases: 1) everything >> you can do without awareness of Java; 2) the rest. >> >> On Tue, Sep 11, 2012 at 10:27 AM, Bill Fenlason <[hidden email] >> <mailto:[hidden email]>> 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? >> >> 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). >> >> A universal installer could be developed with its first step >> being to determine the operating system, by asking if necessary. >> >> There are few if any potential NetRexx users who prefer any kind >> of detailed cookbook installation procedure to an installation >> which is performed in a similar fashion to all the other >> programs he installs. For linux that may be apt, rpm or >> whatever, for windows it will be an installer similar to all the >> other windows installers the user has used, and for OSX it would >> be a process familiar to those users. >> >> I truly do not understand why there is not universal agreement >> to this, since every other position is equivalent to "we want to >> make the installation of NetRexx more difficult than necessary, >> and different from what you are used to". >> >> 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? >> >> Unfortunately I do not have the time or expertise to develop >> these installers or I would do so. _______________________________________________ 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/ |
|
|
Kenneth,
On 9/11/2012 2:31 PM,
[hidden email] wrote:
"one-click" installations only lead to developers who don't understand what is going on under the covers. That may be true (I don't agree), but NetRexx is not only directed at "developers". And it certainly does not prevent developers from understanding the internals if they want to. And much thanks for Kermit's patience is explaining to me how Java finds its compiler. Which is another example of how trying to make something "one click" and fix things for every situation, just muddies the waters. I'm not sure I understand what you are saying - how does a simplified "one click" install cause confusion? Certainly it does not prevent any further explanation of topics such as the JDK conventions. Kenneth Klein Bill _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Aviatrexx
On 9/11/2012 1:47 PM, Chip Davis wrote:
> It appears to me that the NetRexx installer is fundamentally a > bootstrap problem: unless we want to write a custom machine-code > routine for each OS (and nobody does) we need to have a common > platform to examine the host environment in order to properly install > the NetRexx package. It may be true that no one wants to write exe level code for each OS, the reality is that everyone does it, one way or another. > The obvious "common platform" is Java, but until we know where it is, > we can't execute a NetRexx program to find it. So the simple solution > is to include a bootstrap Java compiler (and NetRexx jar) that > provides just enough support, for just long enough, to ascertain the > host environment. The ECJ fits that bill nicely. I don't see how that helps. On windows, how is Java initiated by other than .exe level code? The most commonly used install scenario (windows) is to download an executable file, and to execute it. In other words, download, save the file (and possibly unzip it), then double click on it to execute it. The downloaded file has to be directly executable, and java jars are not. For Windows, the file is a generally a .exe file. For linux, it may be a .rpm file. For Mac, it is generally a .dmg file (I think). Also, I don't think a Java compiler is necessary, since it just produces class files, and the class files can be precompiled. The overall point is that the install process is dependent on the OS and code directly executable by the OS, not Java. Of course the OS dependent code can in effect just issue a java command > Once the Java detector routine has run, there are two possibilities: > it found a working Java compiler, or it didn't. > > In case 1, the installer proceeds to hook NetRexx up to the existing > JDK, and optionally deletes the ECJ. > > In case 2, the installer downloads and installs the latest JDK and > hooks NetRexx to it. > > In both cases, the installer keeps track of every change that it made > to the host environment, so that it can be restored upon uninstall or > upgrade. > > That should cover the "Automatic Install" option. The "Custom > Install" option will prompt for all the pieces and let the user make > all the decisions. > > The novice user gets all the hand-holding of a one-click install. A > user who wants/needs to know all the ingredients in the sausage can > read the Users Guide and/or perform a "Custom Install". > > This sounds to me like more than a SMOP but not impossible. I'm sure > I'm missing several salients points here, so let's hear them. > > -Chip- _______________________________________________ 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 ThSITC
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/ |
Re: eternal headache of the java classpath saga
|
|
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. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by alansam
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/ |
|
|
In reply to this post by billfen
Bill,
it is all a matter of perspective. Installing Oracle the Java SDK on Windows is not that hard; but try z/OS, VAX VMS or iSeries for a change; some of these are non-trivial even if you are the systems programmer. I feel an obligation to cater for all NetRexx users. As it is now, a working Java is a prerequisite. As Mike correctly pointed out, the term 'Java' has become to denote a JRE installation and being delivered tools for programming has become a relatively scarce experience on Windows. Just not on your home machine where you are the admin. 3.02 will contain the installer, and if we cannot pull off something more generic, it will cover at least Windows, Mac and Linux; and it will be of the next;next;finish type. In the meantime, and as a lasting alternative for Eclipse users, we will point to your Eclipse plugin (will change the web site any day now). There will always be cases not covered by any of these, so we will provide the NetRexxC.jar and classpath instructions as we do now. best regards, René. On 2012-09-11 19:03, Bill Fenlason wrote: > Mike, > > If you google "download java compiler" or "download java jdk", the > first link is to an appropriate page. Granted that a google of > "download java" leads you to the runtime download, I would not agree > that Oracle is keeping the download of the JDK difficult. > > The download site for the JDK provides detailed Installation Guides. > e.g: > > > http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installation-windows.html > [1] > > It is clear that the reason that downloading the runtime is the > primary route is because there are huge! numbers of users of the > runtime, and in comparison relatively few compiler users. > > When you download the Java runtime, there is a link entitled "Remove > Older Versions". If your system has 4 runtimes, (and they are out of > date) perhaps you could try that? > > It is reasonable for the older versions to not be removed > automatically, since they may be required for other uses. (e.g. I > have > 1.5, 1.6, and 7 because I need them for testing.) > > Bill > > On 9/11/2012 12:16 PM, Mike Cowlishaw wrote: > >> I didn't fully understand the rationale for the bundling of the ecj >> compiler. Given that Java is such a trouble free installation, I >> don't see why we couldn't just say to new users "first install Java" >> and point them at Sun's page. Then we start from well defined >> initial conditions relatively painlessly. >> >> I think the difficulty here is that "first install Java" once meant >> enough of the Java 'ecosystem' to compile and run Java programs. Now >> it is just the runtime, and it is quite hard for a new Java user to >> search out the compiler, etc., and in fact Oracle seems to to want >> to keep it that way (i.e., hard to do). >> >> Yes, installing the Java runtime is (moderately) trouble-free [but >> why do I have 4 runtimes on my system?]. But getting the compiler to >> work as well is not so easy. >> >> Mike > > > > Links: > ------ > [1] > > http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installation-windows.html _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
On Wed, Sep 12, 2012 at 9:19 AM, rvjansen <[hidden email]> wrote:
René, I´d suggest an advertisement/plug of that great project, "One-Jar" somewhere in the NetRexx docs. I haven´t tested myself with Netrexx code, but it should work. Delivering Java apps as self-contained, portable, single-jar file files (you can place them on a pen drive and run em via javajar appname.jar or doubleclicking on the .jar in Windows) is GREAT. http://one-jar.sourceforge.net/ ----- What is One-JAR?One-JAR lets you package a Java application together with its dependency Jars into a single executable Jar file. Who uses One-JAR?--- http://one-jar.sourceforge.net/index.php?page=introduction&file=background --- The Java Runtime Environment supports running a Jar file using the following syntax: java -jar jarname.jarThe only requirement of the jarname.jar file is that it contains a manifest attribute with the key Main-Class a main class to run, for instance in the META-INF/MANIFEST.MF
file:
Main-Class: com.mydomain.mypackage.MainAny non-trivial Java application is going to rely on any number of supporting Jar files. For example, using the Apache Commons Logging capabilty to do logging an application will need to have the commons-logging.jar
file on its classpath.
Most developers reasonably assume that putting a dependency Jar file into their own Jar file, and adding a Class-Path
attribute to the META-INF/MANIFEST will do the trick:
jarname.jar | /META-INF | | MANIFEST.MF | | Main-Class: com.mydomain.mypackage.Main | | Class-Path: commons-logging.jar | /com/mydomain/mypackage | | Main.class | commons-logging.jarUnfortunately this is does not work. The Java Launcher$AppClassLoader does not know how to load classes from a Jar
inside a Jar with this kind of Class-Path. Trying to use jar:file:jarname.jar!/commons-logging.jar also
leads down a dead-end. This approach will only work if you install (i.e. scatter) the
supporting Jar files into the directory where the jarname.jar file is installed.
Another
approach is to unpack all dependent Jar files and repack them inside the Many popular apps like Java Image Editor are delivered as a single-jar http://www.jhlabs.com/ie/ "Download ImageEditor.jar for Windows and Unix" links to http://www.jhlabs.com/ie/ImageEditor.jar Or see this game delivered as a single-jar version http://www.snorms.com/downloads_demo/snorms-demo.jar?PHPSESSID=e5q5fccq0eut7dv4e2m3c81me0 Basically a single-jar gives you: -Easy app portability (no need to "install" it scattering thousands of files, apps are "self-contained" and movable to any path the user wants to place them -including removable drives like pen drives- without having to fiddle with the system´s path or classpath) -You can package any runtime .jars inside the same jar (no need to copy netrexx runtime to any system path, just package NetRexxR.jar inside your app´s .jar) -No need to include native "launch scripts" or stub exes that call java with the right paths -Just tell the users to double click on the jar (windows) or create a desktop object with java -jar pointing to the .jar file FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: eternal headache of the java classpath saga
|
|
I can vouch for the fact that it works well with NetRexx – both with the C & R jars. Dave. From: [hidden email] [mailto:[hidden email]] On Behalf Of Fernando Cassia On Wed, Sep 12, 2012 at 9:19 AM, rvjansen <[hidden email]> wrote: There will always be cases not covered by any of these, so we will provide the NetRexxC.jar and classpath instructions as we do now.
What is One-JAR?One-JAR lets you package a Java application together with its dependency Jars into a single executable Jar file. Who uses One-JAR?A number of commercial and open-source projects have chosen One-JAR as their packaging mechanism. Since inception One-JAR has had over 75,000 downloads and shows a consistent download profile over time, and is used across a variety of operating-systems The Java Runtime Environment supports running a Jar file using the following syntax: java -jar jarname.jar The only requirement of the jarname.jar file is that it contains a manifest attribute with the key Main-Class: com.mydomain.mypackage.Main Any non-trivial Java application is going to rely on any number of supporting Jar files. For example, using the Apache Commons Logging capabilty to do logging an application will need to have the jarname.jar | /META-INF | | MANIFEST.MF | | Main-Class: com.mydomain.mypackage.Main | | Class-Path: commons-logging.jar | /com/mydomain/mypackage | | Main.class | commons-logging.jar Unfortunately this is does not work. The Java Another approach is to unpack all dependent Jar files and repack them inside the --- _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
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? > 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 operating system, by asking if necessary. > This is being done at the moment. > I truly do not understand why there is not universal agreement to > this, since every other position is equivalent to "we want to make > the > installation of NetRexx more difficult than necessary, and different > from what you are used to". > 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 the OS, or the 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 language siblings here who all need to find their componenents in the same way. You should know how many times 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 enterprise app or keep 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 the issue is being worked on. Tom is doing good work and the results should be visible to everyone soon. best regards, René. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Aviatrexx
Hi Chip,
As designed now, the new installer requires a JRE. The documentation should point to where to get it when you don't have it. I think bootstrap runtimes etc are in the far off future. That does not mean it is unthinkable. The ecj unfortunately does not offer a runtime for bytecode execution. It is a necessary step in providing an installer for the popular platforms with a JRE as a minimal requirement, in which we know we can compile in addition to interpretation. I will try to move the discussion on installers mostly to the developers list - it might be perceived here as an indication of a big problem we have, when in fact it is something we all pass and solve in most cases over list or mail; the installer in 3.02 will make it an even smaller issue. best regards, René. On 2012-09-11 19:47, Chip Davis wrote: > It appears to me that the NetRexx installer is fundamentally a > bootstrap problem: unless we want to write a custom machine-code > routine for each OS (and nobody does) we need to have a common > platform to examine the host environment in order to properly install > the NetRexx package. > > The obvious "common platform" is Java, but until we know where it is, > we can't execute a NetRexx program to find it. So the simple > solution > is to include a bootstrap Java compiler (and NetRexx jar) that > provides just enough support, for just long enough, to ascertain the > host environment. The ECJ fits that bill nicely. > > Once the Java detector routine has run, there are two possibilities: > it found a working Java compiler, or it didn't. > > In case 1, the installer proceeds to hook NetRexx up to the existing > JDK, and optionally deletes the ECJ. > > In case 2, the installer downloads and installs the latest JDK and > hooks NetRexx to it. > > In both cases, the installer keeps track of every change that it made > to the host environment, so that it can be restored upon uninstall or > upgrade. > > That should cover the "Automatic Install" option. The "Custom > Install" option will prompt for all the pieces and let the user make > all the decisions. > > The novice user gets all the hand-holding of a one-click install. A > user who wants/needs to know all the ingredients in the sausage can > read the Users Guide and/or perform a "Custom Install". > > This sounds to me like more than a SMOP but not impossible. I'm sure > I'm missing several salients points here, so let's hear them. > > -Chip- _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Fernando Cassia-2
yes, and apart from naming the tool, this is what IBM suggests in the
helpfile of their Java SDK, in the chapter on extension directories: it is best to include the libraries in your package instead of using the extension directory. On 2012-09-12 14:34, Fernando Cassia wrote: > On Wed, Sep 12, 2012 at 9:19 AM, rvjansen <[hidden email] [1]> > wrote: > >> There will always be cases not covered by any of these, so we will >> provide the NetRexxC.jar and classpath instructions as we do now. >> >> best regards, >> >> René. > > René, > > I´d suggest an advertisement/plug of that great project, "One-Jar" > somewhere in the NetRexx docs. I haven´t tested myself with Netrexx > code, but it should work. Delivering Java apps as self-contained, > portable, single-jar file files (you can place them on a pen drive > and > run em via javajar appname.jar or doubleclicking on the .jar in > Windows) is GREAT. > > http://one-jar.sourceforge.net/ [2] > > ----- > _______________________________________________ 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
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]> wrote: Bill, -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Tom Maynard
On 9/11/2012 6:05 PM, Tom Maynard wrote:
On 9/11/2012 3:10 PM, Kermit Kiser wrote: 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 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. • If you are using an earlier Java version (1.1.2 through 1.1.8) instead 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 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 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. If you are running Java 1.2 or later, 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 above document is certainly out of date, However, the distributed NetRexx 3.01 Release zip file contains the following in the \NetRexx 3.01 Release\documents\NetRexx 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/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |