NetRexx installation revisited
Locked
123
123
 
|
Note: this is only some thinking out aloud; please comment and advice. (warning: long message ahead)
I did some thinking on the issue of having the 'installation' and execution of NetRexx compiles/interpreter runs as painless as possible. It is clear that we have at least three groups of users: - the people who know Java and their platform; - the people coming from other Rexxen trying out the promise of the world of the Java VM and its standardized class libraries; - passers-by maybe entering the world of programming or maybe disillusioned by the runtime performance of jruby and jpython (we have to work on that ;-)) As often is the case, the requirements and needs of these are different. People coming from Java (like myself, I did some Java before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar somewhere, edit the classpath and go. After some reflection and re-reading of past messages I now do agree that the first group does not need to be catered for at all, but the others do. The second group can be catered for with correct and elaborate instructions. My worries here concern the last mentioned group, the passers-by. I am passing by a lot of languages and compilers, and the number one put-off to try and install some compiler is a long list of instructions - there is even some equation in which the lenght of the instruction lists is equal to the failure rate. Thus my proposal would be to have only a modest set of instructions added to the distribution archive; split up in separate pdf files for every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets' should be in the wiki on www.netrexx.org and linked to from these documents - Chip's excellent instruction/verification text should go in there. The passers-by need to be catered for, if only because in the literature describing the history of Rexx, parallells with BASIC and Logo are drawn. We can say what we want about BASIC, the line numbered version, but it has attained its goal of enabling novices to program, and Logo is, I heard, even teachable to 5-years old (although I suspect that would be the crawling turtle part, not the recursive list hierarchy transversal part). These problems are encountered, sometimes in sequence: - java.lang.Object class not found - COM.ibm.netrexx.process.NetRexxC class not found - java compiler tool class not found - there are problems in the example kickoff scripts Different OS platforms have different strategies for the placement of the standard platform JVM (if any), (several) different JVM's can be installed on a platform, and some users may even switch JVMs during the development cycle, for example for the purpose of regression testing. The effects of the combination of, for example, a heterogeneous set of shared libraries and java archives can range from unnoticed to bewildering, to catastrophic. I think the principles on which we base the solutions for the encountered problems, must be to use environmental platform clues as much as possible, and the NetRexx translator itself must be very sparingly (and always relative to the environmental hint) guess where the correct libraries are. Even on MacOSX, where the Java locations were fixed for years, I am encountering two movements: the Apple team thinking of alternative packaging structure, moving eventually to mainstream *nix conventions, and in the meantime offering a program to locate the JAVA_HOME; and the open source Sun JDK7 releases being used as an alternative for people experimenting with InvokeDynamic, tail recursion and other great things to come to the JVM. A subject of discussion is the use of the standard 'blessed' extension directories: they were not always there, they seem to multiply on some platforms, they might work differently among JVM vendors, and I see a high incidence of trouble with people using them. I do not have any problem with a user preference for their use, only I am loathe to advice to use them in the standard install document when this does not turn out to be a totally dependable mechanism. As a side thought - it might hinder understanding of the classpath model, which leads to trouble with the first application that is not in the default package. - a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]'; - platform dependent hints in the translator, relative to a JAVA_HOME environmental setting. For the open source releases we can have minor versions that address changes on the platforms; - a extra System.exec('java') when the Java compiler class cannot be found (funny enough a successful Java SDK enables the javac, which is a very thin native invoker executable for a Java program, to find its compiler class) One snag here is that fetching environment variables has been deprected in Java for a number of years (not every platform - phones - have them) but since that seems to be reversed, and other language processors use them, I gather we are safe here for the future. For the moment, I would like to avoid a native or Java-installer approach that needs all this knowledge of platforms and possible combinations of JVM releases on machines out there. But I would certainly not oppose someone to pick this up and support this. A separate 'Building applications for NetRexx' document, should contain chapters on package and directory structure, and touch subjects like the use of 'make', 'ant' and 'maven', class-in-source or not, generating Javadoc, how to handle dependencies, etc. On a side thought, I wonder if our planned cpan-like repository could be a maven repository. The 'Building' document should explain about how to structure for NetRexx web apps using J2EE packaging conventions for JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers to start building this information. Please let me know what you think - I already know that we would like the open source release to happen soon - but we can do so much as a community already before that happens. I will try to have the wiki up somewhere this weekend. It will be a JSPWiki, not the slickest around, but it enables us to extend it and brand the site NetRexx - powered. It will probably start out with three projects on it - installation, building and IDE - but even the table of contents will be user-editable. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
Hi All,
There is a lot to digest here. I'd just like to comment on one peripheral issue touched on in the last paragraph ("NetRexx - powered"). Do we/should we/can we have a logo indicating "NetRexx powered!"? I'd love to display it (and the crafted with jEdit logo) on a product I'm developing. George Hovey On Sat, Mar 13, 2010 at 9:14 AM, René Jansen <[hidden email]> wrote: Note: this is only some thinking out aloud; please comment and advice. (warning: long message ahead) _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
I suggest we mention this to Mark Hessling who has several "Rexx-Powered" icons
on his Regina http://regina-rexx.sourceforge.net/ website. Designing a kicky logo is harder than it would seem. -Chip- On 3/13/10 15:40 George Hovey said: > Hi All, > > There is a lot to digest here. I'd just like to comment on one > peripheral issue touched on in the last paragraph ("NetRexx - > powered"). Do we/should we/can we have a logo indicating "NetRexx > powered!"? I'd love to display it (and the crafted with jEdit logo) on > a product I'm developing. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by rvjansen
Indeed, this is a non-trivial problem. As you might have guessed, I've done
fair amount of analysis myself and come to essentially the same conclusions. My analysis differs in that I see only two groups because recent experience shows that there is a great deal of overlap in the "Rexx-experienced" and the "passers-by" groups insofar as the Java environment is concerned. Thus, my solution to the problem is simpler: a stone-simple, one click install for the newbies, and everyone else gets a comprehensive description of the installation dependencies, various optional installation schemes, and copious documentation of why things are the way they are. That would all be in a 'read.me.next' file in the package as well as on the wiki. If someone is comfortable in the OS and Java environments, we want to give them everything they need to know. For everyone else, it's "click here and magic occurs". The main way I would accomplish the "one-click install" is by simply giving them no choices. It's unlikely that such a naïve user has moved the JDK somewhere from its default location, so we simply verify that it is where it should be, create a NetRexx directory where is should be, and set everything up with those locations hardcoded in the execution script. I'm not a huge fan of shell scripts or .bat files, but I don't see any reason why they would not be capable of dynamically creating a working execution script for the "passers-by". If they don't like it, those with the skills and inclination are welcome to customize it. The only environment variable that _might_ need to be updated (and I'm not wild about doing that) is the PATH so that we don't have to stuff the execution script in 'Java/jre_/bin/client'. I'm open to suggestion as to which would be the better approach, since many newbies won't have a private '/bin' of their own, and the Java folks seem to have created the 'client' directory for just this purpose. AFAICT, there is no reason to touch the 'CLASSPATH' variable at all, nowadays. I had hoped to have a block of time to work on this before now but that has not been the case. If I were more adept at Java, it should be possible to write a single program that would do the installation on all the platforms. Especially if we eschew updating environment variables. -Chip- On 3/13/10 14:14 René Jansen said: > Note: this is only some thinking out aloud; please comment and advice. (warning: long message ahead) > > I did some thinking on the issue of having the 'installation' and execution of NetRexx compiles/interpreter runs as painless as possible. It is clear that we have at least three groups of users: > > - the people who know Java and their platform; > - the people coming from other Rexxen trying out the promise of the world of the Java VM and its standardized class libraries; > - passers-by maybe entering the world of programming or maybe disillusioned by the runtime performance of jruby and jpython (we have to work on that ;-)) > > As often is the case, the requirements and needs of these are different. People coming from Java (like myself, I did some Java before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx package, but with earlier Rexx experience on MVS, OS/2 and NT) generally have no issues, drop the jar somewhere, edit the classpath and go. After some reflection and re-reading of past messages I now do agree that the first group does not need to be catered for at all, but the others do. The second group can be catered for with correct and elaborate instructions. My worries here concern the last mentioned group, the passers-by. I am passing by a lot of languages and compilers, and the number one put-off to try and install some compiler is a long list of instructions - there is even some equation in which the lenght of the instruction lists is equal to the failure rate. > > Thus my proposal would be to have only a modest set of instructions added to the distribution archive; split up in separate pdf files for every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The 'elaborate sets' should be in the wiki on www.netrexx.org and linked to from these documents - Chip's excellent instruction/verification text should go in there. > > The passers-by need to be catered for, if only because in the literature describing the history of Rexx, parallells with BASIC and Logo are drawn. We can say what we want about BASIC, the line numbered version, but it has attained its goal of enabling novices to program, and Logo is, I heard, even teachable to 5-years old (although I suspect that would be the crawling turtle part, not the recursive list hierarchy transversal part). > > These problems are encountered, sometimes in sequence: > > - java.lang.Object class not found > - COM.ibm.netrexx.process.NetRexxC class not found > - java compiler tool class not found > - there are problems in the example kickoff scripts > > Different OS platforms have different strategies for the placement of the standard platform JVM (if any), (several) different JVM's can be installed on a platform, and some users may even switch JVMs during the development cycle, for example for the purpose of regression testing. The effects of the combination of, for example, a heterogeneous set of shared libraries and java archives can range from unnoticed to bewildering, to catastrophic. > > I think the principles on which we base the solutions for the encountered problems, must be to use environmental platform clues as much as possible, and the NetRexx translator itself must be very sparingly (and always relative to the environmental hint) guess where the correct libraries are. Even on MacOSX, where the Java locations were fixed for years, I am encountering two movements: the Apple team thinking of alternative packaging structure, moving eventually to mainstream *nix conventions, and in the meantime offering a program to locate the JAVA_HOME; and the open source Sun JDK7 releases being used as an alternative for people experimenting with InvokeDynamic, tail recursion and other great things to come to the JVM. > > A subject of discussion is the use of the standard 'blessed' extension directories: they were not always there, they seem to multiply on some platforms, they might work differently among JVM vendors, and I see a high incidence of trouble with people using them. I do not have any problem with a user preference for their use, only I am loathe to advice to use them in the standard install document when this does not turn out to be a totally dependable mechanism. As a side thought - it might hinder understanding of the classpath model, which leads to trouble with the first application that is not in the default package. > > - a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]'; > - platform dependent hints in the translator, relative to a JAVA_HOME environmental setting. For the open source releases we can have minor versions that address changes on the platforms; > - a extra System.exec('java') when the Java compiler class cannot be found (funny enough a successful Java SDK enables the javac, which is a very thin native invoker executable for a Java program, to find its compiler class) > > One snag here is that fetching environment variables has been deprected in Java for a number of years (not every platform - phones - have them) but since that seems to be reversed, and other language processors use them, I gather we are safe here for the future. > > For the moment, I would like to avoid a native or Java-installer approach that needs all this knowledge of platforms and possible combinations of JVM releases on machines out there. But I would certainly not oppose someone to pick this up and support this. > > A separate 'Building applications for NetRexx' document, should contain chapters on package and directory structure, and touch subjects like the use of 'make', 'ant' and 'maven', class-in-source or not, generating Javadoc, how to handle dependencies, etc. On a side thought, I wonder if our planned cpan-like repository could be a maven repository. The 'Building' document should explain about how to structure for NetRexx web apps using J2EE packaging conventions for JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers to start building this information. > > Please let me know what you think - I already know that we would like the open source release to happen soon - but we can do so much as a community already before that happens. I will try to have the wiki up somewhere this weekend. It will be a JSPWiki, not the slickest around, but it enables us to extend it and brand the site NetRexx - powered. It will probably start out with three projects on it - installation, building and IDE - but even the table of contents will be user-editable. > > best regards, > > René Jansen. > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
Hi Chip
1.) Thanks for all of your efforts so far. 2.) Might I strongly *advocate* to *remove* all references to moving things around manually *should be removed* from the Readme. 3.) might I also suggest to have ONE, and *only* one 'environment path variable' necessary, for instance NetRexx_HOME. 4.) As Rene is currently preparing (and hopefulle finishing very soon) the open source release of NetRexx, then all we others *COULD* adapt very easily to the new style, i.e. put our tools below the Netrexx HOME directory. Tom. ================================================================== Chip Davis schrieb: > Indeed, this is a non-trivial problem. As you might have guessed, > I've done fair amount of analysis myself and come to essentially the > same conclusions. > > My analysis differs in that I see only two groups because recent > experience shows that there is a great deal of overlap in the > "Rexx-experienced" and the "passers-by" groups insofar as the Java > environment is concerned. > > Thus, my solution to the problem is simpler: a stone-simple, one click > install for the newbies, and everyone else gets a comprehensive > description of the installation dependencies, various optional > installation schemes, and copious documentation of why things are the > way they are. That would all be in a 'read.me.next' file in the > package as well as on the wiki. If someone is comfortable in the OS > and Java environments, we want to give them everything they need to > know. For everyone else, it's "click here and magic occurs". > > The main way I would accomplish the "one-click install" is by simply > giving them no choices. It's unlikely that such a naïve user has > moved the JDK somewhere from its default location, so we simply verify > that it is where it should be, create a NetRexx directory where is > should be, and set everything up with those locations hardcoded in the > execution script. I'm not a huge fan of shell scripts or .bat files, > but I don't see any reason why they would not be capable of > dynamically creating a working execution script for the "passers-by". > > If they don't like it, those with the skills and inclination are > welcome to customize it. > > The only environment variable that _might_ need to be updated (and I'm > not wild about doing that) is the PATH so that we don't have to stuff > the execution script in 'Java/jre_/bin/client'. I'm open to > suggestion as to which would be the better approach, since many > newbies won't have a private '/bin' of their own, and the Java folks > seem to have created the 'client' directory for just this purpose. > AFAICT, there is no reason to touch the 'CLASSPATH' variable at all, > nowadays. > > I had hoped to have a block of time to work on this before now but > that has not been the case. > > If I were more adept at Java, it should be possible to write a single > program that would do the installation on all the platforms. > Especially if we eschew updating environment variables. > > -Chip- > > On 3/13/10 14:14 René Jansen said: >> Note: this is only some thinking out aloud; please comment and >> advice. (warning: long message ahead) >> >> I did some thinking on the issue of having the 'installation' and >> execution of NetRexx compiles/interpreter runs as painless as >> possible. It is clear that we have at least three groups of users: >> - the people who know Java and their platform; >> - the people coming from other Rexxen trying out the promise of the >> world of the Java VM and its standardized class libraries; >> - passers-by maybe entering the world of programming or maybe >> disillusioned by the runtime performance of jruby and jpython (we >> have to work on that ;-)) >> >> As often is the case, the requirements and needs of these are >> different. People coming from Java (like myself, I did some Java >> before discovering NetRexx through Ed Tomlinson's Pipes for NetRexx >> package, but with earlier Rexx experience on MVS, OS/2 and NT) >> generally have no issues, drop the jar somewhere, edit the classpath >> and go. After some reflection and re-reading of past messages I now >> do agree that the first group does not need to be catered for at all, >> but the others do. The second group can be catered for with correct >> and elaborate instructions. My worries here concern the last >> mentioned group, the passers-by. I am passing by a lot of languages >> and compilers, and the number one put-off to try and install some >> compiler is a long list of instructions - there is even some equation >> in which the lenght of the instruction lists is equal to the failure >> rate. >> >> Thus my proposal would be to have only a modest set of instructions >> added to the distribution archive; split up in separate pdf files for >> every major platform (Wintel, Linux-x86, Linux-Z, Aix, MacOSX). The >> 'elaborate sets' should be in the wiki on www.netrexx.org and linked >> to from these documents - Chip's excellent instruction/verification >> text should go in there. >> >> The passers-by need to be catered for, if only because in the >> literature describing the history of Rexx, parallells with BASIC and >> Logo are drawn. We can say what we want about BASIC, the line >> numbered version, but it has attained its goal of enabling novices to >> program, and Logo is, I heard, even teachable to 5-years old >> (although I suspect that would be the crawling turtle part, not the >> recursive list hierarchy transversal part). >> >> These problems are encountered, sometimes in sequence: >> >> - java.lang.Object class not found >> - COM.ibm.netrexx.process.NetRexxC class not found >> - java compiler tool class not found >> - there are problems in the example kickoff scripts >> >> Different OS platforms have different strategies for the placement of >> the standard platform JVM (if any), (several) different JVM's can be >> installed on a platform, and some users may even switch JVMs during >> the development cycle, for example for the purpose of regression >> testing. The effects of the combination of, for example, a >> heterogeneous set of shared libraries and java archives can range >> from unnoticed to bewildering, to catastrophic. >> >> I think the principles on which we base the solutions for the >> encountered problems, must be to use environmental platform clues as >> much as possible, and the NetRexx translator itself must be very >> sparingly (and always relative to the environmental hint) guess where >> the correct libraries are. Even on MacOSX, where the Java locations >> were fixed for years, I am encountering two movements: the Apple team >> thinking of alternative packaging structure, moving eventually to >> mainstream *nix conventions, and in the meantime offering a program >> to locate the JAVA_HOME; and the open source Sun JDK7 releases being >> used as an alternative for people experimenting with InvokeDynamic, >> tail recursion and other great things to come to the JVM. >> >> A subject of discussion is the use of the standard 'blessed' >> extension directories: they were not always there, they seem to >> multiply on some platforms, they might work differently among JVM >> vendors, and I see a high incidence of trouble with people using >> them. I do not have any problem with a user preference for their use, >> only I am loathe to advice to use them in the standard install >> document when this does not turn out to be a totally dependable >> mechanism. As a side thought - it might hinder understanding of the >> classpath model, which leads to trouble with the first application >> that is not in the default package. >> >> - a package-less 'nrc' class in the jar that has a main that calls >> the translator for a compile, and a .manifest file that declares that >> main, enabling users to start a compile with 'java -jar NetRexxC.jar >> SourceFile[.nrx]'; >> - platform dependent hints in the translator, relative to a JAVA_HOME >> environmental setting. For the open source releases we can have minor >> versions that address changes on the platforms; >> - a extra System.exec('java') when the Java compiler class cannot be >> found (funny enough a successful Java SDK enables the javac, which is >> a very thin native invoker executable for a Java program, to find its >> compiler class) >> >> One snag here is that fetching environment variables has been >> deprected in Java for a number of years (not every platform - phones >> - have them) but since that seems to be reversed, and other language >> processors use them, I gather we are safe here for the future. >> >> For the moment, I would like to avoid a native or Java-installer >> approach that needs all this knowledge of platforms and possible >> combinations of JVM releases on machines out there. But I would >> certainly not oppose someone to pick this up and support this. >> >> A separate 'Building applications for NetRexx' document, should >> contain chapters on package and directory structure, and touch >> subjects like the use of 'make', 'ant' and 'maven', class-in-source >> or not, generating Javadoc, how to handle dependencies, etc. On a >> side thought, I wonder if our planned cpan-like repository could be a >> maven repository. The 'Building' document should explain about how to >> structure for NetRexx web apps using J2EE packaging conventions for >> JBoss, Glassfish and WebSphere. Obviously I would welcome volunteers >> to start building this information. >> >> Please let me know what you think - I already know that we would like >> the open source release to happen soon - but we can do so much as a >> community already before that happens. I will try to have the wiki up >> somewhere this weekend. It will be a JSPWiki, not the slickest >> around, but it enables us to extend it and brand the site NetRexx - >> powered. It will probably start out with three projects on it - >> installation, building and IDE - but even the table of contents will >> be user-editable. >> >> best regards, >> >> René Jansen. >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by Aviatrexx
True; mostly - the issue at stake is that the people that have previously experienced Rexx generally show enormous commitment and perseverance to get NetRexx to work. We are not surprised at this, knowing the wealth, the joy, the 'it should work like this, let me try it before looking it up', low astonishment factor nature of Rexx, etc. Or at least I like to think so.
The passer-by (or a member of one of my teams shown the link to NetRexx with a warning to know this stuff after the weekend) is, in general, much more fickle; without Java experience people tend to read until the word 'classpath' is mentioned. I entirely agree about the one-click installer, but I have major worries about its feasability. There is no such thing as a default location, as I tried to indicate: even on platforms that have a standard JVM in a default location, this varies over time. Even my Windows partitions (ok, I admit to having several of those, all VM, and only for professional reasons) each have several JVMs, some that I use for testing, others just arrived with products, and an old one in the browser). This leads to the NetRexx installation paradox - while you actually only need NetRexxC.jar, and one or two additions to CLASSPATH (probably lost readers by putting this in uppercase), the crafting together of a one-click automatic installer is extremely non-trivial. Let me remind you that some products include a JVM to counter this problem, then switch the default one to theirs during installation. Even the extremely naive user might have gotten a work laptop that contains an IBM JRE only in the default path - I happen to know of several thousands of those laptops. To avoid this installer going to take up all my time, I am not going to attempt it now. I will, however, gladly contribute to the design, although probably only with complications. I will be extremely grateful if someone cobbles something together that works. In my previous email, I expressed my vision on this issue; with a short repeat in different words: - there is no reason to modify PATH, as there is no real reason to use a script to kickoff NetRexx. If we shorten COM.ibm.netrexx.process.NetRexxC to (package-less) nrc, it can be kicked of by 'java nrc sourcefile[.nrx]'. None of my Makefiles specify a script to compile anymore; locating that script is more work and creates a dependency. I learned this the hard way when someone for no reason (might have erased it by accident and re-created it wrongly) modified the script on one machine to accept only a limited number of parameters and I spent hours to find that out. - most serious usages need CLASSPATH, however this sometimes is contradicted in popular literature: but try to develop a multi-package application without adding the package root directory to your classpath: you will need to make a jar before you can test every time. Make that before you can build with package dependencies. Note that this also is neatly done for you by the support that an IDE delivers, so in that universe it is a correct statement. This leads me to think that if we are able to deliver NetRexx as a JEdit, NetRexxDE or Eclipse package, with enough support and integration, we have solved a large part of the problem. David's environment should be available from the JEdit plugin manager site soon, so we can get some experience using that. The large advantage here is: if you are looking at JEdit, you have a running Java. If David specifies where the NetRexx jar should go (until we just can include it), we can point new users to that 'guaranteed to work' environment. best regards, René Jansen. On 13 mrt 2010, at 22:45, Chip Davis wrote: > Indeed, this is a non-trivial problem. As you might have guessed, I've done fair amount of analysis myself and come to essentially the same conclusions. > > My analysis differs in that I see only two groups because recent experience shows that there is a great deal of overlap in the "Rexx-experienced" and the "passers-by" groups insofar as the Java environment is concerned. > > Thus, my solution to the problem is simpler: a stone-simple, one click install for the newbies, and everyone else gets a comprehensive description of the installation dependencies, various optional installation schemes, and copious documentation of why things are the way they are. That would all be in a 'read.me.next' file in the package as well as on the wiki. If someone is comfortable in the OS and Java environments, we want to give them everything they need to know. For everyone else, it's "click here and magic occurs". > > The main way I would accomplish the "one-click install" is by simply giving them no choices. It's unlikely that such a naïve user has moved the JDK somewhere from its default location, so we simply verify that it is where it should be, create a NetRexx directory where is should be, and set everything up with those locations hardcoded in the execution script. I'm not a huge fan of shell scripts or .bat files, but I don't see any reason why they would not be capable of dynamically creating a working execution script for the "passers-by". > > If they don't like it, those with the skills and inclination are welcome to customize it. > > The only environment variable that _might_ need to be updated (and I'm not wild about doing that) is the PATH so that we don't have to stuff the execution script in 'Java/jre_/bin/client'. I'm open to suggestion as to which would be the better approach, since many newbies won't have a private '/bin' of their own, and the Java folks seem to have created the 'client' directory for just this purpose. AFAICT, there is no reason to touch the 'CLASSPATH' variable at all, nowadays. > > I had hoped to have a block of time to work on this before now but that has not been the case. > > If I were more adept at Java, it should be possible to write a single program that would do the installation on all the platforms. Especially if we eschew updating environment variables. > > -Chip- > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 René Jansen schrieb am 14.03.2010 15:05: > - there is no reason to modify PATH, as there is no real reason to use a script to kickoff NetRexx. If we shorten COM.ibm.netrexx.process.NetRexxC to (package-less) nrc, it can be kicked of by 'java nrc sourcefile[.nrx]'. None of my Makefiles specify a script to compile anymore; locating that script is more work and creates a dependency. I learned this the hard way when someone for no reason (might have erased it by accident and re-created it wrongly) modified the script on one machine to accept only a limited number of parameters and I spent hours to find that out. > > - most serious usages need CLASSPATH, however this sometimes is contradicted in popular literature: but try to develop a multi-package application without adding the package root directory to your classpath: you will need to make a jar before you can test every time. Make that before you can build with package dependencies. Note that this also is neatly done for you by the support that an IDE delivers, so in that universe it is a correct statement. Hi, may I make a guess how to solve this rather uncomplicated: - - we package a startable jar, so that we just have to use java -jar nrc.jar. We could easily provide many "starter-jars", as they can refer other jars via manifest entries. - - using the JDT compiler instead of relying upon the javac compiler (and on the user installing a jdk instead of the mostly preinstalled jre). The JDT compiler is very compact and would enable a "instant on" experience for the user. - - the only missing part would be some start scripts firing off the JVM with -jar [command].jar throwing through all parameters given. Or a small GUI doing that... Comments? - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkudI+sACgkQfGgGu8y7ypB6gwCg4ppu8a6FRlOml9ZYtEP6UQdH n0cAn1kiAkSYPa1qwlxgzq/9a2RkVJNX =nInX -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
One comment: great!
Where do I get JDT? Do you have a dowload link? Cannot see the wood from the trees in Eclpse-land. best regards, René. On 14 mrt 2010, at 18:59, Patric Bechtel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > René Jansen schrieb am 14.03.2010 15:05: >> - there is no reason to modify PATH, as there is no real reason to use a script to kickoff NetRexx. If we shorten COM.ibm.netrexx.process.NetRexxC to (package-less) nrc, it can be kicked of by 'java nrc sourcefile[.nrx]'. None of my Makefiles specify a script to compile anymore; locating that script is more work and creates a dependency. I learned this the hard way when someone for no reason (might have erased it by accident and re-created it wrongly) modified the script on one machine to accept only a limited number of parameters and I spent hours to find that out. >> >> - most serious usages need CLASSPATH, however this sometimes is contradicted in popular literature: but try to develop a multi-package application without adding the package root directory to your classpath: you will need to make a jar before you can test every time. Make that before you can build with package dependencies. Note that this also is neatly done for you by the support that an IDE delivers, so in that universe it is a correct statement. > > Hi, > > may I make a guess how to solve this rather uncomplicated: > > - - we package a startable jar, so that we just have to use java -jar > nrc.jar. We could easily provide many "starter-jars", as they can refer > other jars via manifest entries. > > - - using the JDT compiler instead of relying upon the javac compiler (and > on the user installing a jdk instead of the mostly preinstalled jre). > The JDT compiler is very compact and would enable a "instant on" > experience for the user. > > - - the only missing part would be some start scripts firing off the JVM > with -jar [command].jar throwing through all parameters given. Or a > small GUI doing that... > > Comments? > > - -- > Patric > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: GnuPT 2.5.2 > > iEYEARECAAYFAkudI+sACgkQfGgGu8y7ypB6gwCg4ppu8a6FRlOml9ZYtEP6UQdH > n0cAn1kiAkSYPa1qwlxgzq/9a2RkVJNX > =nInX > -----END PGP SIGNATURE----- > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 René Jansen schrieb am 14.03.2010 19:43: > One comment: great! > > Where do I get JDT? Do you have a dowload link? Cannot see the wood from the trees in Eclpse-land. Hi René, nice to hear you like it :-) Download it here: http://download.eclipse.org/eclipse/downloads/drops/R-3.5.2-201002111343/download.php?dropFile=ecj-3.5.2.jar How to use it: http://dev.eclipse.org/viewcvs/index.cgi/jdt-core-home/howto/batch%20compile/batchCompile.html?revision=1.7 - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkudNj8ACgkQfGgGu8y7ypDldQCfcLMH0X7hzs/WdncTHIpo5qei 1X8An0ePNUbWQj4Uv0aMsJWsBvedDSwr =Id4t -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
In reply to this post by rvjansen
On Sat, Mar 13, 2010 at 11:14 AM, René Jansen <[hidden email]> wrote:
> - a package-less 'nrc' class in the jar that has a main that calls the translator for a compile, and a .manifest file that declares that main, enabling users to start a compile with 'java -jar NetRexxC.jar SourceFile[.nrx]'; This is the right and only way to do things, imho. :) End users shouldn´t have to mess with the classpath. PERIOD. FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by rvjansen
René, to use Mike's wonderful expression: I think we are in violent agreement
here. :-) I like your idea of using a package-less invocation for the Passer-By User (henceforth "PBU") installation. It would solve the annoying PATH/CLASSPATH issue and eliminate a whole set of support issues. I don't think it will work in practice, however. Basically, AFAICT you either have to move the 'tools.jar' file into the active JRE, or include it in the CLASSPATH, or specify it in the '-cp' flag on the 'java' invocation. Of those three options, the latter is the least-problematic, imho. So that brings us back to providing an invocation script. I can live with that, given the complexities introduced by the alternatives. As far as I'm concerned, the PBU is the only user that needs an install script. Someone with an environment such as yours is on his own :-) albeit with the benefit of the copious textual documentation we will provide. It would be quite a challenge to design an install script smart enough to make sense of a complex multi-JVM environment, so we shouldn't even try. My assumption is that the PBU JDK environment will be relatively deterministic, either by being in whatever default location(s) that platform uses, or findable with a little bit of script-work. For example, it could do a brute-force search for "lib/tools.jar" and if it finds more or less than one instance, it throws up its hands and terminates with a sensible message, which will be explained in the documentation. Yes, it's entirely possible that other products might provide a JRE of their own, but there should jolly-well be only one JDK on a PBU platform. We don't really care how many JREs are on a platform, or where they are, as long as one of them gets invoked by the 'java' command, do we? By the same token, the PBU NetRexx environment is also standardized to the platform. If the PBU wants to move things around, he takes himself out of the PBU category and accepts the responsibility to read the docs and make it work. Non-PBUs will need to be fully conversant with PATH/CLASSPATH and a host of other issues which we (by which I mean "you" ;-) will document for their edification. I wish I was as sanguine about the difference between PBUs with Rexx experience and those without, but I submit that immediate past experience should indicate otherwise. They may be more motivated (an tenacious) but not necessarily more knowledgeable of Java or their OS environment. They need the same hand-holding as non-Rexx PBUs. Let me try my hand at writing a PBU .bat and .bash script and see how far I get. You may feel free to start on the non-PBU documentation of the specifics of what has to go where, and why, for NetRexx to work with a JDK. Who knows, someone else reading this may beat us both to the punch... ;-) -Chip- On 3/14/10 14:05 René Jansen said: > True; mostly - the issue at stake is that the people that have previously experienced Rexx generally show enormous commitment and perseverance to get NetRexx to work. We are not surprised at this, knowing the wealth, the joy, the 'it should work like this, let me try it before looking it up', low astonishment factor nature of Rexx, etc. Or at least I like to think so. > > The passer-by (or a member of one of my teams shown the link to NetRexx with a warning to know this stuff after the weekend) is, in general, much more fickle; without Java experience people tend to read until the word 'classpath' is mentioned. > > I entirely agree about the one-click installer, but I have major worries about its feasability. There is no such thing as a default location, as I tried to indicate: even on platforms that have a standard JVM in a default location, this varies over time. Even my Windows partitions (ok, I admit to having several of those, all VM, and only for professional reasons) each have several JVMs, some that I use for testing, others just arrived with products, and an old one in the browser). This leads to the NetRexx installation paradox - while you actually only need NetRexxC.jar, and one or two additions to CLASSPATH (probably lost readers by putting this in uppercase), the crafting together of a one-click automatic installer is extremely non-trivial. > > Let me remind you that some products include a JVM to counter this problem, then switch the default one to theirs during installation. Even the extremely naive user might have gotten a work laptop that contains an IBM JRE only in the default path - I happen to know of several thousands of those laptops. > > To avoid this installer going to take up all my time, I am not going to attempt it now. I will, however, gladly contribute to the design, although probably only with complications. I will be extremely grateful if someone cobbles something together that works. > > In my previous email, I expressed my vision on this issue; with a short repeat in different words: > > - there is no reason to modify PATH, as there is no real reason to use a script to kickoff NetRexx. If we shorten COM.ibm.netrexx.process.NetRexxC to (package-less) nrc, it can be kicked of by 'java nrc sourcefile[.nrx]'. None of my Makefiles specify a script to compile anymore; locating that script is more work and creates a dependency. I learned this the hard way when someone for no reason (might have erased it by accident and re-created it wrongly) modified the script on one machine to accept only a limited number of parameters and I spent hours to find that out. > > - most serious usages need CLASSPATH, however this sometimes is contradicted in popular literature: but try to develop a multi-package application without adding the package root directory to your classpath: you will need to make a jar before you can test every time. Make that before you can build with package dependencies. Note that this also is neatly done for you by the support that an IDE delivers, so in that universe it is a correct statement. > > This leads me to think that if we are able to deliver NetRexx as a JEdit, NetRexxDE or Eclipse package, with enough support and integration, we have solved a large part of the problem. David's environment should be available from the JEdit plugin manager site soon, so we can get some experience using that. The large advantage here is: if you are looking at JEdit, you have a running Java. If David specifies where the NetRexx jar should go (until we just can include it), we can point new users to that 'guaranteed to work' environment. > > best regards, > > René Jansen. > > > On 13 mrt 2010, at 22:45, Chip Davis wrote: > >> Indeed, this is a non-trivial problem. As you might have guessed, I've done fair amount of analysis myself and come to essentially the same conclusions. >> >> My analysis differs in that I see only two groups because recent experience shows that there is a great deal of overlap in the "Rexx-experienced" and the "passers-by" groups insofar as the Java environment is concerned. >> >> Thus, my solution to the problem is simpler: a stone-simple, one click install for the newbies, and everyone else gets a comprehensive description of the installation dependencies, various optional installation schemes, and copious documentation of why things are the way they are. That would all be in a 'read.me.next' file in the package as well as on the wiki. If someone is comfortable in the OS and Java environments, we want to give them everything they need to know. For everyone else, it's "click here and magic occurs". >> >> The main way I would accomplish the "one-click install" is by simply giving them no choices. It's unlikely that such a naïve user has moved the JDK somewhere from its default location, so we simply verify that it is where it should be, create a NetRexx directory where is should be, and set everything up with those locations hardcoded in the execution script. I'm not a huge fan of shell scripts or .bat files, but I don't see any reason why they would not be capable of dynamically creating a working execution script for the "passers-by". >> >> If they don't like it, those with the skills and inclination are welcome to customize it. >> >> The only environment variable that _might_ need to be updated (and I'm not wild about doing that) is the PATH so that we don't have to stuff the execution script in 'Java/jre_/bin/client'. I'm open to suggestion as to which would be the better approach, since many newbies won't have a private '/bin' of their own, and the Java folks seem to have created the 'client' directory for just this purpose. AFAICT, there is no reason to touch the 'CLASSPATH' variable at all, nowadays. >> >> I had hoped to have a block of time to work on this before now but that has not been the case. >> >> If I were more adept at Java, it should be possible to write a single program that would do the installation on all the platforms. Especially if we eschew updating environment variables. >> >> -Chip- >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
In reply to this post by rvjansen
On Sun, Mar 14, 2010 at 11:05 AM, René Jansen <[hidden email]> wrote:
> Let me remind you that some products include a JVM to counter this problem, then switch the default one to theirs during installation. This is ridiculous and developers who do this shouldn´t be shipping Java apps in the first place. Yes, I´ve seen such apps, and yes, most of these firms have gone under, thank God. (Prismiq was one of them, shipping a JVM 1.4.x at the time there was a 1.5.x available with many less bugs). Let´s try not to promote bad practices that Sun does not recommend. In fact, "JVM proliferation" is something the new Java installers on Windows try to avoid by updating Java versions rather than leaving the old one behind... http://blogs.pcmag.com/securitywatch/2008/08/java_will_solve_old_version_pr.php FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
In reply to this post by Patric Bechtel
Patric Bechtel wrote:
Another option to consider: Janino. From the webpage:- - using the JDT compiler instead of relying upon the javac compiler (and on the user installing a jdk instead of the mostly preinstalled jre). The JDT compiler is very compact and would enable a "instant on" experience for the user. Janino is a compiler that reads a JavaTM expression, block, class body, source file or a set of source files, and generates JavaTM bytecode that is loaded and executed directly. Janino is not intended to be a development tool, but an embedded compiler for run-time compilation purposes, e.g. expression evaluators or "server pages" engines like JSP. JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and JBoss Rules / Drools. JANINO can also be used for static code analysis or code manipulation. The webpage is http://docs.codehaus.org/display/JANINO/Home. Otherwise I have no knowledge or experience with the application. I'm just keeping the group's options open (I hope).Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Tom Maynard schrieb am 15.03.2010 04:05: > Patric Bechtel wrote: >> - - using the JDT compiler instead of relying upon the javac compiler (and >> on the user installing a jdk instead of the mostly preinstalled jre). >> The JDT compiler is very compact and would enable a "instant on" >> experience for the user. >> >> > Another option to consider: Janino. From the webpage: Hi, I'm aware of Janino, and for the current language set, it would be almost a possible alternative - but it misses asserts, apart from some other, hopefully soon to come features for NetRexx, such as Annotations, enums or varargs. But yeah, that's basically the path to go, isn't it? - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkud6osACgkQfGgGu8y7ypDFKwCgxFyudxfcI8tdIk1Xjj+e/P6b 9JMAoLPTfStVM1gOCv9oXo05cMsoPCkr =Vm7v -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
Hello Patrick,
I am aware of assertions and enums. Could you please explain for me what Annotations are? thanks, Tom. ====================================================== Patric Bechtel schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Maynard schrieb am 15.03.2010 04:05: > >> Patric Bechtel wrote: >> >>> - - using the JDT compiler instead of relying upon the javac compiler (and >>> on the user installing a jdk instead of the mostly preinstalled jre). >>> The JDT compiler is very compact and would enable a "instant on" >>> experience for the user. >>> >>> >>> >> Another option to consider: Janino. From the webpage: >> > > Hi, > > I'm aware of Janino, and for the current language set, it would be > almost a possible alternative - but it misses asserts, apart from some > other, hopefully soon to come features for NetRexx, such as Annotations, > enums or varargs. > > But yeah, that's basically the path to go, isn't it? > > - -- > Patric > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: GnuPT 2.5.2 > > iEYEARECAAYFAkud6osACgkQfGgGu8y7ypDFKwCgxFyudxfcI8tdIk1Xjj+e/P6b > 9JMAoLPTfStVM1gOCv9oXo05cMsoPCkr > =Vm7v > -----END PGP SIGNATURE----- > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
Re: NetRexx installation revisited
|
|
In reply to this post by Aviatrexx
Just to put in my personal opinion:
For the inexperienced user, we should try to enforce David's NetRexxDE and Kermit's NetRexxScript. As Rene said, installing JEdit would *imply* that the necessary underlying Java environment is already active. We should, therefore, promote the usage of JEdit, as a first step, und leave the batch files for console invocation for the 'experienced users' only. This also would be valuable as an argument that NetRexx as such has *NO IDE* available. Whereas the existance of an IDE seems to be the most important for young programmers, as opposed to the many very experienced Rexx dinos there at the Rexx goup , which learned programming without IDE's. Tom. ================================================================= Chip Davis schrieb: > René, to use Mike's wonderful expression: I think we are in violent > agreement here. :-) > > I like your idea of using a package-less invocation for the Passer-By > User (henceforth "PBU") installation. It would solve the annoying > PATH/CLASSPATH issue and eliminate a whole set of support issues. I > don't think it will work in practice, however. > > Basically, AFAICT you either have to move the 'tools.jar' file into > the active JRE, or include it in the CLASSPATH, or specify it in the > '-cp' flag on the 'java' invocation. Of those three options, the > latter is the least-problematic, imho. So that brings us back to > providing an invocation script. I can live with that, given the > complexities introduced by the alternatives. > > As far as I'm concerned, the PBU is the only user that needs an > install script. > > Someone with an environment such as yours is on his own :-) albeit > with the benefit of the copious textual documentation we will > provide. It would be quite a challenge to design an install script > smart enough to make sense of a complex multi-JVM environment, so we > shouldn't even try. > > My assumption is that the PBU JDK environment will be relatively > deterministic, either by being in whatever default location(s) that > platform uses, or findable with a little bit of script-work. For > example, it could do a brute-force search for "lib/tools.jar" and if > it finds more or less than one instance, it throws up its hands and > terminates with a sensible message, which will be explained in the > documentation. Yes, it's entirely possible that other products might > provide a JRE of their own, but there should jolly-well be only one > JDK on a PBU platform. > We don't really care how many JREs are on a platform, or where they > are, as long as one of them gets invoked by the 'java' command, do we? > > By the same token, the PBU NetRexx environment is also standardized to > the platform. If the PBU wants to move things around, he takes > himself out of the PBU category and accepts the responsibility to read > the docs and make it work. > > Non-PBUs will need to be fully conversant with PATH/CLASSPATH and a > host of other issues which we (by which I mean "you" ;-) will document > for their edification. > > I wish I was as sanguine about the difference between PBUs with Rexx > experience and those without, but I submit that immediate past > experience should indicate otherwise. They may be more motivated (an > tenacious) but not necessarily more knowledgeable of Java or their OS > environment. They need the same hand-holding as non-Rexx PBUs. > > Let me try my hand at writing a PBU .bat and .bash script and see how > far I get. You may feel free to start on the non-PBU documentation of > the specifics of what has to go where, and why, for NetRexx to work > with a JDK. Who knows, someone else reading this may beat us both to > the punch... ;-) > > -Chip- > > On 3/14/10 14:05 René Jansen said: >> True; mostly - the issue at stake is that the people that have >> previously experienced Rexx generally show enormous commitment and >> perseverance to get NetRexx to work. We are not surprised at this, >> knowing the wealth, the joy, the 'it should work like this, let me >> try it before looking it up', low astonishment factor nature of Rexx, >> etc. Or at least I like to think so. >> >> The passer-by (or a member of one of my teams shown the link to >> NetRexx with a warning to know this stuff after the weekend) is, in >> general, much more fickle; without Java experience people tend to >> read until the word 'classpath' is mentioned. >> >> I entirely agree about the one-click installer, but I have major >> worries about its feasability. There is no such thing as a default >> location, as I tried to indicate: even on platforms that have a >> standard JVM in a default location, this varies over time. Even my >> Windows partitions (ok, I admit to having several of those, all VM, >> and only for professional reasons) each have several JVMs, some that >> I use for testing, others just arrived with products, and an old one >> in the browser). This leads to the NetRexx installation paradox - >> while you actually only need NetRexxC.jar, and one or two additions >> to CLASSPATH (probably lost readers by putting this in uppercase), >> the crafting together of a one-click automatic installer is extremely >> non-trivial. >> >> Let me remind you that some products include a JVM to counter this >> problem, then switch the default one to theirs during installation. >> Even the extremely naive user might have gotten a work laptop that >> contains an IBM JRE only in the default path - I happen to know of >> several thousands of those laptops. >> >> To avoid this installer going to take up all my time, I am not going >> to attempt it now. I will, however, gladly contribute to the design, >> although probably only with complications. I will be extremely >> grateful if someone cobbles something together that works. >> >> In my previous email, I expressed my vision on this issue; with a >> short repeat in different words: >> >> - there is no reason to modify PATH, as there is no real reason to >> use a script to kickoff NetRexx. If we shorten >> COM.ibm.netrexx.process.NetRexxC to (package-less) nrc, it can be >> kicked of by 'java nrc sourcefile[.nrx]'. None of my Makefiles >> specify a script to compile anymore; locating that script is more >> work and creates a dependency. I learned this the hard way when >> someone for no reason (might have erased it by accident and >> re-created it wrongly) modified the script on one machine to accept >> only a limited number of parameters and I spent hours to find that out. >> >> - most serious usages need CLASSPATH, however this sometimes is >> contradicted in popular literature: but try to develop a >> multi-package application without adding the package root directory >> to your classpath: you will need to make a jar before you can test >> every time. Make that before you can build with package dependencies. >> Note that this also is neatly done for you by the support that an IDE >> delivers, so in that universe it is a correct statement. >> >> This leads me to think that if we are able to deliver NetRexx as a >> JEdit, NetRexxDE or Eclipse package, with enough support and >> integration, we have solved a large part of the problem. David's >> environment should be available from the JEdit plugin manager site >> soon, so we can get some experience using that. The large advantage >> here is: if you are looking at JEdit, you have a running Java. If >> David specifies where the NetRexx jar should go (until we just can >> include it), we can point new users to that 'guaranteed to work' >> environment. >> >> best regards, >> >> René Jansen. >> >> >> On 13 mrt 2010, at 22:45, Chip Davis wrote: >> >>> Indeed, this is a non-trivial problem. As you might have guessed, >>> I've done fair amount of analysis myself and come to essentially the >>> same conclusions. >>> >>> My analysis differs in that I see only two groups because recent >>> experience shows that there is a great deal of overlap in the >>> "Rexx-experienced" and the "passers-by" groups insofar as the Java >>> environment is concerned. >>> >>> Thus, my solution to the problem is simpler: a stone-simple, one >>> click install for the newbies, and everyone else gets a >>> comprehensive description of the installation dependencies, various >>> optional installation schemes, and copious documentation of why >>> things are the way they are. That would all be in a 'read.me.next' >>> file in the package as well as on the wiki. If someone is >>> comfortable in the OS and Java environments, we want to give them >>> everything they need to know. For everyone else, it's "click here >>> and magic occurs". >>> >>> The main way I would accomplish the "one-click install" is by simply >>> giving them no choices. It's unlikely that such a naïve user has >>> moved the JDK somewhere from its default location, so we simply >>> verify that it is where it should be, create a NetRexx directory >>> where is should be, and set everything up with those locations >>> hardcoded in the execution script. I'm not a huge fan of shell >>> scripts or .bat files, but I don't see any reason why they would not >>> be capable of dynamically creating a working execution script for >>> the "passers-by". >>> >>> If they don't like it, those with the skills and inclination are >>> welcome to customize it. >>> >>> The only environment variable that _might_ need to be updated (and >>> I'm not wild about doing that) is the PATH so that we don't have to >>> stuff the execution script in 'Java/jre_/bin/client'. I'm open to >>> suggestion as to which would be the better approach, since many >>> newbies won't have a private '/bin' of their own, and the Java folks >>> seem to have created the 'client' directory for just this purpose. >>> AFAICT, there is no reason to touch the 'CLASSPATH' variable at all, >>> nowadays. >>> >>> I had hoped to have a block of time to work on this before now but >>> that has not been the case. >>> >>> If I were more adept at Java, it should be possible to write a >>> single program that would do the installation on all the platforms. >>> Especially if we eschew updating environment variables. >>> >>> -Chip- >>> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by Thomas.Schneider.Wien
Tom,
have a Google for Java Annotations, or have a look at http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html best regards, René. On Mon, Mar 15, 2010 at 10:51 AM, Thomas Schneider <[hidden email]> wrote: > Hello Patrick, > I am aware of assertions and enums. > > Could you please explain for me what Annotations are? > thanks, Tom. > ====================================================== > Patric Bechtel schrieb: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tom Maynard schrieb am 15.03.2010 04:05: >> >>> >>> Patric Bechtel wrote: >>> >>>> >>>> - - using the JDT compiler instead of relying upon the javac compiler >>>> (and >>>> on the user installing a jdk instead of the mostly preinstalled jre). >>>> The JDT compiler is very compact and would enable a "instant on" >>>> experience for the user. >>>> >>>> >>> >>> Another option to consider: Janino. From the webpage: >>> >> >> Hi, >> >> I'm aware of Janino, and for the current language set, it would be >> almost a possible alternative - but it misses asserts, apart from some >> other, hopefully soon to come features for NetRexx, such as Annotations, >> enums or varargs. >> >> But yeah, that's basically the path to go, isn't it? >> >> - -- >> Patric >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: GnuPT 2.5.2 >> >> iEYEARECAAYFAkud6osACgkQfGgGu8y7ypDFKwCgxFyudxfcI8tdIk1Xjj+e/P6b >> 9JMAoLPTfStVM1gOCv9oXo05cMsoPCkr >> =Vm7v >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Tom Maynard
Patric,
thanks for this valuable pointer. OTOH, NetRexx has already impressive bytecode generation features in the interpreter part; as always, it is about carefully introducing or leaving out dependencies. I had a look at the Eclipse JDT - it requires one to speficy a Java rt.jar - it would solve the JRE problem but not all the location problems. Next thing I am going to look at is the source of javac - the launcher, not the Java compiler part, and see what that has to offer in terms of inspiration. best regards, René. On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard <[hidden email]> wrote: > Patric Bechtel wrote: > > - - using the JDT compiler instead of relying upon the javac compiler (and > on the user installing a jdk instead of the mostly preinstalled jre). > The JDT compiler is very compact and would enable a "instant on" > experience for the user. > > > > Another option to consider: Janino. From the webpage: > > Janino is a compiler that reads a JavaTM expression, block, class body, > source file or a set of source files, and generates JavaTM bytecode that is > loaded and executed directly. Janino is not intended to be a development > tool, but an embedded compiler for run-time compilation purposes, e.g. > expression evaluators or "server pages" engines like JSP. > > JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and > JBoss Rules / Drools. > > JANINO can also be used for static code analysis or code manipulation. > > The webpage is http://docs.codehaus.org/display/JANINO/Home. Otherwise I > have no knowledge or experience with the application. I'm just keeping the > group's options open (I hope). > > Tom. > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: NetRexx installation revisited
|
|
In reply to this post by rvjansen
Hello Rene,
1.) Many thanks for the link. 2.) just read it. Everythink clear, except: Questions: Must annotations be in comments ? *Or* is the preferred syntax just @annotion { parameters ...} (as shown in your link) Has anybody already though about how the NetRexx Syntax for enumarations, assertions, and annotations in NetRexx *should be* ? Personally, I did introduce the following syntax for assertions in NetRexx: <simple statement> :: <relop> value (on the same line) (combined with a class ReyAssert, which checks the assertions at run-time. Is this syntax for assertions acceptable by the public ? Tom. =================================================================== René Jansen schrieb: > Tom, > > have a Google for Java Annotations, > > or have a look at > http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html > > best regards, > > René. > > On Mon, Mar 15, 2010 at 10:51 AM, Thomas Schneider <[hidden email]> wrote: > >> Hello Patrick, >> I am aware of assertions and enums. >> >> Could you please explain for me what Annotations are? >> thanks, Tom. >> ====================================================== >> Patric Bechtel schrieb: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Tom Maynard schrieb am 15.03.2010 04:05: >>> >>> >>>> Patric Bechtel wrote: >>>> >>>> >>>>> - - using the JDT compiler instead of relying upon the javac compiler >>>>> (and >>>>> on the user installing a jdk instead of the mostly preinstalled jre). >>>>> The JDT compiler is very compact and would enable a "instant on" >>>>> experience for the user. >>>>> >>>>> >>>>> >>>> Another option to consider: Janino. From the webpage: >>>> >>>> >>> Hi, >>> >>> I'm aware of Janino, and for the current language set, it would be >>> almost a possible alternative - but it misses asserts, apart from some >>> other, hopefully soon to come features for NetRexx, such as Annotations, >>> enums or varargs. >>> >>> But yeah, that's basically the path to go, isn't it? >>> >>> - -- >>> Patric >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> Comment: GnuPT 2.5.2 >>> >>> iEYEARECAAYFAkud6osACgkQfGgGu8y7ypDFKwCgxFyudxfcI8tdIk1Xjj+e/P6b >>> 9JMAoLPTfStVM1gOCv9oXo05cMsoPCkr >>> =Vm7v >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >>> >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
Re: NetRexx installation revisited
|
|
In reply to this post by rvjansen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Hi René, the rt.jar location could probably be parsed out of the url by asking for a well-known resource like "/java/lang/String.class", the path is before the exclamation mark, just like this: say String.class.getResource('/java/lang/String.class') gives jar:file:/usr/lib/jvm/jdk1.6.0_18/jre/lib/rt.jar!/java/lang/String.class :-) Patric René Jansen schrieb am 15.03.2010 11:15: > Patric, > > thanks for this valuable pointer. OTOH, NetRexx has already impressive > bytecode generation features in the interpreter part; as always, it is > about carefully introducing or leaving out dependencies. > > I had a look at the Eclipse JDT - it requires one to speficy a Java > rt.jar - it would solve the JRE problem but not all the location > problems. Next thing I am going to look at is the source of javac - > the launcher, not the Java compiler part, and see what that has to > offer in terms of inspiration. > > best regards, > > René. > > On Mon, Mar 15, 2010 at 4:05 AM, Tom Maynard <[hidden email]> wrote: >> Patric Bechtel wrote: >> >> - - using the JDT compiler instead of relying upon the javac compiler (and >> on the user installing a jdk instead of the mostly preinstalled jre). >> The JDT compiler is very compact and would enable a "instant on" >> experience for the user. >> >> >> >> Another option to consider: Janino. From the webpage: >> >> Janino is a compiler that reads a JavaTM expression, block, class body, >> source file or a set of source files, and generates JavaTM bytecode that is >> loaded and executed directly. Janino is not intended to be a development >> tool, but an embedded compiler for run-time compilation purposes, e.g. >> expression evaluators or "server pages" engines like JSP. >> >> JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and >> JBoss Rules / Drools. >> >> JANINO can also be used for static code analysis or code manipulation. >> >> The webpage is http://docs.codehaus.org/display/JANINO/Home. Otherwise I >> have no knowledge or experience with the application. I'm just keeping the >> group's options open (I hope). >> >> Tom. >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkueFn8ACgkQfGgGu8y7ypAnrwCePJp4RwpCGDcGweSVDNxk6w05 bycAoIICT1M5efx5JHS2RZTXvSMJy0FS =YGTK -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |