Call for help with tools.jar locater algorithm.

[rickmcguire]

On Thu, Sep 22, 2011 at 4:00 PM, Kermit Kiser <[hidden email]> wrote:

> Actually the requirement for Java 1.5 was technically only to build the
> NetRexx translator itself so that the developers could know what features
> were available to code changes with.
>
> I think we also assumed that it would apply to the runtime environment for
> NetRexx so that we could be sure that any changes that passed through to the
> Java code would work and that we did not need to test everything with every
> old version of Java. In reality, I don't think any of the new features
> require more than Java 1.4 at this point and code that does not use any new
> features would probably still compile and run with even older versions of
> Java. Testing that would be a nightmare I think and looking toward future
> enhancement we definitely need a specific target that we can require and
> test with. I would have preferred Java 1.6 as it has been released and open
> source for 5 years now and includes the compiler API and JSR223, but 1.5 was
> the compromise reached by René after taking into account the fact that
> legacy code could still run with NetRexx 3.00 if it needed an older Java
> environment.
>
> As far as allowing NetRexx to create byte-code without the presence of a
> Java compiler, I agree with Mike. If possible, it would be far better to
> give NetRexx the option to produce the byte-code directly than to depend on
> something like Janino for which we do not control the code! I have no idea
> how difficult that would be since I have not studied byte-code at all but
> Mike seems to think it would not be too difficult. Has anyone looked into
> that yet?

There are plenty of open source class file manipulation libraries out
there that make that a much easier job.  The libraries handle all of
the mechanics of the class file format and the generation code only
needs to worry about emitting the correct byte code for the program
logic.

Rick

>
> -- Kermit
>
>
> On 9/22/2011 6:26 AM, David Requena wrote:
>
> There are 3 different "Java" levels we need to consider here:
> - Level needed to actually run the NetRexx Translator, affecting which
> environments can be used for NetRexx development.
> - Level of the translated intermediate java code, affecting
> which Java compilers can be used to emit byte-code as a second step.
> - Level of final byte-code, affecting which runtime environments are
> supported for NetRexx programs (also influenced by the level to which the
> runtime itself was compiled)
> It is unclear to me to what are we referring when we say "we have targeted
> Java 1.5 for NetRexx support".
> Is it about point one above? Point two? Both?
>
>
> 2011/9/22 Rony G. Flatscher <[hidden email]>
>>
>> On 22.09.2011 11:46, [hidden email] wrote:
>> > Being able to interface with different Java compilers is of course
>> > useful.
>> > Once NetRexx adopts the standard API, it will be able to use any
>> > compiler
>> > that uses it (and supports the Java that NetRexx generates).
>> >
>> The problem seems to be that before 1.6/6 there is no standard compiler
>> installed with Java. Hence the need to locate, get and install the JDK
>> or any other Java compiler in order for NetRexx to be even able to
>> compile.
>>
>> Finding, installing and configuring the compiler is easy for guys like
>> you and me who have no problems locating, installing and configuring it.
>>
>> It has turned into a hell for many others, who have had no prior
>> exposure to Java. We have been witnessing this problem quite a few times
>> by following the postings of newcomers and learning about the problems
>> they face. (Some of these problems would never surface for Java-savvy
>> people, because they know which paths are fruitless to take. Yet, for a
>> human-oriented philosophy NetRexx should me made as easy to use as
>> possible and not having the users to hunt down for fulfilling
>> dependencies, which nowadays could be incorporated into the NetRexx
>> distribution, thereby adding a big chunk of relief.)
>>
>> Even, if a NetRexx developer can be expected to eventually locate and
>> develop the necessary knowledge to install and configure a Java compiler
>> this may pose a rather big problem if thinking about deploying NetRexx
>> applications in the field that need for one reason or another the
>> ability to e.g. compile NetRexx programs. For these use-cases having a
>> compiler on board of the NetRexx distribution would solve the problem.
>> This would also solve the problem for NetRexx developers who have been
>> exposed to Rexx, but not necessarily to Java development.
>>
>>
>> ---rony
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>
>
>
> --
> Saludos / Regards,
> David Requena
>
>
> _______________________________________________
> 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/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 22.09.2011 22:00, Kermit Kiser wrote:

I think we also assumed that it would apply to the runtime environment for NetRexx so that we could be sure that any changes that passed through to the Java code would work and that we did not need to test everything with every old version of Java. In reality, I don't think any of the new features require more than Java 1.4 at this point and code that does not use any new features would probably still compile and run with even older versions of Java. Testing that would be a nightmare I think and looking toward future enhancement we definitely need a specific target that we can require and test with. I would have preferred Java 1.6 as it has been released and open source for 5 years now and includes the compiler API and JSR223, but 1.5 was the compromise reached by René after taking into account the fact that legacy code could still run with NetRexx 3.00 if it needed an older Java environment.

JSR-223 is available in an opensource implementation from Apache for Java 1.4 and 1.5. The Apache name is "BSF 3" (note the version number "3" which indicates that it implements JSR-223)! Adding this to a NetRexx distribution package demands a baseline of Java 1.4. (If deploying such a NetRexx package on Java 1.6/6 or higher would automatically cause the Java 1.6/6 or higher implementation of javax.script to be used instead, due to the set forth Java rules for loading classes.)

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 22.09.2011 22:33, Rick McGuire wrote:

> On Thu, Sep 22, 2011 at 4:00 PM, Kermit Kiser <[hidden email]> wrote:
>  
>> As far as allowing NetRexx to create byte-code without the presence of a
>> Java compiler, I agree with Mike. If possible, it would be far better to
>> give NetRexx the option to produce the byte-code directly than to depend on
>> something like Janino for which we do not control the code! I have no idea
>> how difficult that would be since I have not studied byte-code at all but
>> Mike seems to think it would not be too difficult. Has anyone looked into
>> that yet?
>>    
>
> There are plenty of open source class file manipulation libraries out
> there that make that a much easier job.  The libraries handle all of
> the mechanics of the class file format and the generation code only
> needs to worry about emitting the correct byte code for the program
> logic.
>  

One such package is e.g. "asm" from <http://asm.ow2.org/>, which is also
used in manipulating class files (e.g. to turn a Java 1.6 class file
into one that Java 1.1 can process, cf. retroweaver; actually quite easy
to implement with asm).  A brief FAQ can be found here:
<http://asm.ow2.org/doc/faq.html>, the developer guide at:
<http://asm.ow2.org/doc/developer-guide.html>.

"asm" is actively developed and a new major release (4.0) is coming up,
there is e.g. an Eclipse bytecode outline plugin (cf.
<http://asm.ow2.org/eclipse/index.html>). Here's a list of some products
using asm: <http://asm.ow2.org/users.html>.

---rony

P.S.: Employed that to dynamically create Java classes for BSF4ooRexx
needs on the fly. asm is used to allow callbacks from Java to ooRexx
objects by creating Java classes on the fly that incorporate the
forwarding logic.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 22.09.2011 17:08, Tom Maynard wrote:

On 9/22/2011 5:24 AM, Rony G. Flatscher wrote:

Finding, installing and configuring the compiler is easy for guys like
you and me who have no problems locating, installing and configuring it.

Ahem.  I have to take issue with this (at least partially).  I've been working (fighting?) with Java since its 1.0 days, and installing NetRexx each and every time I did was a near nightmare.  Put tools.jar where?  Adjust the classpath how?  I shudder even now as I remember the struggle.

The core of the problem seems to be that the NetRexx package is not self-contained in the sense, that one is able to take immediately advantage in full of it after installation.

What is missing is a compiler being on board/part of the NetRexx package, such that no other dependencies exist for the developers and users of NetRexx.

To alleviate this nasty (and counter-productive) and big problem for most, adding an opensource, license compatible Java compiler would fill the bill for the time being. If the compiler gets added to the NetRexx distribution (to the NetRexx jar) itself is also capable of taking advantage of the 1.6/6 and later compilers, then it would solve a big usability/deployment problem for NetRexx. And it would solve it now.

Adding Janino or the like to NetRexx would not mean that some future developments are not possible, but rather, that the current drop of NetRexx can finally run without a need to hunt down the needed compiler.

To make this flexible, one could change the current NetRexx code to fall back to Janino or the like, if the NetRexx-expected Java compiler cannot be found. This way, the execution paths remain the same for installations and developers who have managed to spot tools.jar and incorporate it. Newcomers (developers as well as users), however, who have no real clues about this specifity are safe as well, being able to use NetRexx in full without any further hazzles.

I would put the priority of a NetRexx installer right at the top of the list -- such a high priority that ... <gulp> ... I'm volunteering to work on the project myself!  Give me the requirements list (at least for Windows now) and I'll have a whack at it.  I'm getting ready to migrate to a brand new machine and installing Java/NetRexx is right at the top of my list.

deploying NetRexx
applications in the field

This topic has come up before (several times), and the OneJar (or similar) approach seems to be a workable solution ... given some work to tailor it suitably for NetRexx.

As you asked for it, some specs:
:)

• Ask the user whether it should get installed for the current user only or systemwide for all users.
  
• Create a batch file to start the NetRexx programs in which you set the correct class path.
• Add file-type associations to execute NetRexx/Java with it (defined for the current user or the current local machine).
• Allow some reinstall logic to account for updates to newer Javas to use for NetRexx. (Java on Windows usually has all necessary information stored in the registry.)
• Add an uninstall option to cleanly uninstall NetRexx from the registry and the file system.
  

HTH,

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Without bothering you too much...

Rene and I did investigate generating BYTE Code directly some time ago.

Whil'st this has not been actually done, the INTERNAL DECL and CODE
I'm personally using in my tools might be a quite good starting point
for this,
as it will not make the RxTranslator more and more complex.

Thomas Schneider.
========================================================
Am 22.09.2011 22:33, schrieb Rick McGuire:

> On Thu, Sep 22, 2011 at 4:00 PM, Kermit Kiser<[hidden email]>  wrote:
>> Actually the requirement for Java 1.5 was technically only to build the
>> NetRexx translator itself so that the developers could know what features
>> were available to code changes with.
>>
>> I think we also assumed that it would apply to the runtime environment for
>> NetRexx so that we could be sure that any changes that passed through to the
>> Java code would work and that we did not need to test everything with every
>> old version of Java. In reality, I don't think any of the new features
>> require more than Java 1.4 at this point and code that does not use any new
>> features would probably still compile and run with even older versions of
>> Java. Testing that would be a nightmare I think and looking toward future
>> enhancement we definitely need a specific target that we can require and
>> test with. I would have preferred Java 1.6 as it has been released and open
>> source for 5 years now and includes the compiler API and JSR223, but 1.5 was
>> the compromise reached by René after taking into account the fact that
>> legacy code could still run with NetRexx 3.00 if it needed an older Java
>> environment.
>>
>> As far as allowing NetRexx to create byte-code without the presence of a
>> Java compiler, I agree with Mike. If possible, it would be far better to
>> give NetRexx the option to produce the byte-code directly than to depend on
>> something like Janino for which we do not control the code! I have no idea
>> how difficult that would be since I have not studied byte-code at all but
>> Mike seems to think it would not be too difficult. Has anyone looked into
>> that yet?
>
> There are plenty of open source class file manipulation libraries out
> there that make that a much easier job.  The libraries handle all of
> the mechanics of the class file format and the generation code only
> needs to worry about emitting the correct byte code for the program
> logic.
>
> Rick
>
>> -- Kermit
>>
>>
>> On 9/22/2011 6:26 AM, David Requena wrote:
>>
>> There are 3 different "Java" levels we need to consider here:
>> - Level needed to actually run the NetRexx Translator, affecting which
>> environments can be used for NetRexx development.
>> - Level of the translated intermediate java code, affecting
>> which Java compilers can be used to emit byte-code as a second step.
>> - Level of final byte-code, affecting which runtime environments are
>> supported for NetRexx programs (also influenced by the level to which the
>> runtime itself was compiled)
>> It is unclear to me to what are we referring when we say "we have targeted
>> Java 1.5 for NetRexx support".
>> Is it about point one above? Point two? Both?
>>
>>
>> 2011/9/22 Rony G. Flatscher<[hidden email]>
>>> On 22.09.2011 11:46, [hidden email] wrote:
>>>> Being able to interface with different Java compilers is of course
>>>> useful.
>>>> Once NetRexx adopts the standard API, it will be able to use any
>>>> compiler
>>>> that uses it (and supports the Java that NetRexx generates).
>>>>
>>> The problem seems to be that before 1.6/6 there is no standard compiler
>>> installed with Java. Hence the need to locate, get and install the JDK
>>> or any other Java compiler in order for NetRexx to be even able to
>>> compile.
>>>
>>> Finding, installing and configuring the compiler is easy for guys like
>>> you and me who have no problems locating, installing and configuring it.
>>>
>>> It has turned into a hell for many others, who have had no prior
>>> exposure to Java. We have been witnessing this problem quite a few times
>>> by following the postings of newcomers and learning about the problems
>>> they face. (Some of these problems would never surface for Java-savvy
>>> people, because they know which paths are fruitless to take. Yet, for a
>>> human-oriented philosophy NetRexx should me made as easy to use as
>>> possible and not having the users to hunt down for fulfilling
>>> dependencies, which nowadays could be incorporated into the NetRexx
>>> distribution, thereby adding a big chunk of relief.)
>>>
>>> Even, if a NetRexx developer can be expected to eventually locate and
>>> develop the necessary knowledge to install and configure a Java compiler
>>> this may pose a rather big problem if thinking about deploying NetRexx
>>> applications in the field that need for one reason or another the
>>> ability to e.g. compile NetRexx programs. For these use-cases having a
>>> compiler on board of the NetRexx distribution would solve the problem.
>>> This would also solve the problem for NetRexx developers who have been
>>> exposed to Rexx, but not necessarily to Java development.
>>>
>>>
>>> ---rony
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>
>>
>> --
>> Saludos / Regards,
>> David Requena
>>
>>
>> _______________________________________________
>> 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/
>>
>>
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider (Founder of www.thsitc.com) 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/

[rvjansen]

Tom (M),

as more people called Tom have offered to occupy themselves with the
installer, I would like to take you up on the offer, but officially to
gather the requirements first. If you can do that, we can coordinate the
actual work later; I am sure it entails much more than what most of us
are thinking now.

I seem to remember that in an earlier discussion there were many
proponents of a single, platform independent installer. Our platform
higher up being Java, this seems feasible.

Of course, this installer should be modular and incorporate knowledge
of many different platforms. I propose that we (you - if you take the
assignment) first gather requirements, design and then (incrementally)
build.

To point out some of the difficulties:

- some users have a large number of VM's visible on an lpar
- some filesystems are case insensitive, tolerate spaces in names, some
do not
- some platforms have separate security for reading, writing and
executing
- some have different conventions or notions of batchfiles - NetRexx on
OMVS runs with JCL, for example
- having a specified classpath in a batchfile should not obscure the
already set classpath
- for beginners, the Eclipse and JEdit plugins probably provide a
working system far better than an installer can
- for knowledgeable users, you don't need an install procedure
- including a compiler would obviate most of the problems.

I am certain that there is something workable between all these
constraints. I would suggest having a hard look at what JRuby and Jython
or Jacl do for installing. When we decide not to have one platform
independent installer, there is always the way of separate RPM, .dmg,
.msi etcetera installers. It would be a good thing if these would
implement the same overall strategy.

We should first state general principles, like:

- you don't have to use the installer if you don't want to, we keep
delivering the jars
- it should ask no questions, at least, not if they are avoidable
- it should not surprise people who are used to install other languages
on top of the JVM
- it should not make NetRexx look bad or unprofessional
- contributed libraries can be optionally (check the boxes) installed
- does it check for and suggest updates?
- is it tied in with a maven-like or eclipse-like repository system, so
we can install a minimum and have it pull in libraries as needed

Then we should make decisions on some of the complications stated
above:

- do we ask the user to choose between found JVM/JRE/SDK's, should we
check if these do work
- do we default to the JVM that is running the install (seems
dangerous, but at least, it runs)

Then, with installers possibly complicating the error situations (used
by less knowledgeable users, etc, on system configurations not
anticipated, etc), who is going to support these (not only the code, but
also the lists and incidents)?

Maybe it is good to structure these a bit, and have chapters per
platform (I see overlap with the (not in existence yet) chapters in the
User Guide).

Apologies for the brain dump, but I am actually expected to do other
things now.

best regards,

Rene.

>
> * Ask the user whether it should get installed for the current user
> only or systemwide for all users.
>   * Create a batch file to start the NetRexx programs in which you
> set the correct class path.
>   * Add file-type associations to execute NetRexx/Java with it
> (defined for the current user or the current local machine).
>   * Allow some reinstall logic to account for updates to newer Javas
> to use for NetRexx. (Java on Windows usually has all necessary
> information stored in the registry.)
>
> * Add an uninstall option to cleanly uninstall NetRexx from the
> registry and the file system.
>
>  HTH,
>
>  ---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Rene,
Thanks for the brain dump.  Very sobering: plainly, this will generate a lot of back and forth about different platforms etc that will require future reference.

Would it help to introduce some minimal structure into the discussion, say by specifying that issues be reported to a formally named series of threads (Installation Part I, etc with a maximum size) which effectively act as a journal?  Or perhaps Kenai has some mechanism for dealing with this.
George

On Fri, Sep 23, 2011 at 7:55 AM, rvjansen <[hidden email]> wrote:

Tom (M),

as more people called Tom have offered to occupy themselves with the installer, I would like to take you up on the offer, but officially to gather the requirements first. If you can do that, we can coordinate the actual work later; I am sure it entails much more than what most of us are thinking now.

I seem to remember that in an earlier discussion there were many proponents of a single, platform independent installer. Our platform higher up being Java, this seems feasible.

Of course, this installer should be modular and incorporate knowledge of many different platforms. I propose that we (you - if you take the assignment) first gather requirements, design and then (incrementally) build.

To point out some of the difficulties:

- some users have a large number of VM's visible on an lpar
- some filesystems are case insensitive, tolerate spaces in names, some do not
- some platforms have separate security for reading, writing and executing
- some have different conventions or notions of batchfiles - NetRexx on OMVS runs with JCL, for example
- having a specified classpath in a batchfile should not obscure the already set classpath
- for beginners, the Eclipse and JEdit plugins probably provide a working system far better than an installer can
- for knowledgeable users, you don't need an install procedure
- including a compiler would obviate most of the problems.

I am certain that there is something workable between all these constraints. I would suggest having a hard look at what JRuby and Jython or Jacl do for installing. When we decide not to have one platform independent installer, there is always the way of separate RPM, .dmg, .msi etcetera installers. It would be a good thing if these would implement the same overall strategy.

We should first state general principles, like:

- you don't have to use the installer if you don't want to, we keep delivering the jars
- it should ask no questions, at least, not if they are avoidable
- it should not surprise people who are used to install other languages on top of the JVM
- it should not make NetRexx look bad or unprofessional
- contributed libraries can be optionally (check the boxes) installed
- does it check for and suggest updates?
- is it tied in with a maven-like or eclipse-like repository system, so we can install a minimum and have it pull in libraries as needed

Then we should make decisions on some of the complications stated above:

- do we ask the user to choose between found JVM/JRE/SDK's, should we check if these do work
- do we default to the JVM that is running the install (seems dangerous, but at least, it runs)

Then, with installers possibly complicating the error situations (used by less knowledgeable users, etc, on system configurations not anticipated, etc), who is going to support these (not only the code, but also the lists and incidents)?

Maybe it is good to structure these a bit, and have chapters per platform (I see overlap with the (not in existence yet) chapters in the User Guide).

Apologies for the brain dump, but I am actually expected to do other things now.

best regards,

Rene.

       * Ask the user whether it should get installed for the current user

only or systemwide for all users.
       * Create a batch file to start the NetRexx programs in which you
set the correct class path.
       * Add file-type associations to execute NetRexx/Java with it
(defined for the current user or the current local machine).
       * Allow some reinstall logic to account for updates to newer Javas
to use for NetRexx. (Java on Windows usually has all necessary
information stored in the registry.)

       * Add an uninstall option to cleanly uninstall NetRexx from the
registry and the file system.

 HTH,

 ---rony

_______________________________________________
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/

[Mike Cowlishaw]

> > As far as allowing NetRexx to create byte-code without the
> > presence of
> > a Java compiler, I agree with Mike. If possible, it would be far
> > better to give NetRexx the option to produce the byte-code directly
> > than to depend on something like Janino for which we do not control
> > the code! I have no idea how difficult that would be since
> > I have not
> > studied byte-code at all but Mike seems to think it would
> > not be too
> > difficult. Has anyone looked into that yet?
>
>
> There are plenty of open source class file manipulation
> libraries out there that make that a much easier job.  The
> libraries handle all of the mechanics of the class file
> format and the generation code only needs to worry about
> emitting the correct byte code for the program logic.

NetRexx already has class file reading/parsing code.  I forget how far I went
down the line of generating class files.  But they aren't complicated.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

rvjansen <[hidden email]> wrote:

>the installer, I would like to take you up on the offer

Geez, did I say that out loud?!  I guess I must have ... especially now that my inbox is piling up with requirements specs.  <sigh>


>gather the requirements first. If you can do that

Why, I'll even consult my brother ... who is the certified -- wait for it -- PMP in the family.  I'm sure he'll get a good laugh out of it as well.  "You volunteered for *WHAT*?!"


>I am sure it entails much more than what most of us
>are thinking now.

Oh, there's no question about that ... especially since (before yesterday) I hadn't been thinking about it at all.


Sent from my Motorola ATRIX™ 4G on AT&T

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Robert L Hamilton]

NetRexxDE is installed and working on a newer laptop(w/ XP SP3) but I have been stymied in trying to install it on an older Desktop(w/ XP SP3).  This was an attempt to interest a local 'For-Profit' school chain in looking at NetRexx.  This is the first time I have been completely unable to deal with any Rexx from ObjRexx on out to NetRexx.  Steve Swift got ooRexx 4.+ running in CGI-BIN on a server at ukservers.net and we had talked about installing NetRexxC also, but there has to be an easier way to deal w/  NetRexx installation .  I'm not giving up on the project but it is in abeyance until NetRexx can be installed on selected PC venues.

Thank you all for the help and enjoy the Day.

Robert L Hamilton, Engineer
Richardson Texas USA   

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

I don't recall seeing any detailed description of your environment or the procedure you followed along with the resulting symptoms. I don't think anyone can help you without knowing exactly what you are dealing with. If you really want to resolve your issue, I suggest that you run the program that I created and post the results back to the list. That will probably take you a long way towards getting the help you need.

http://kenai.com/projects/netrexx-plus/downloads/download/Envirotest/envirotest.class

to run it: java envirotest

-- KK


On 9/23/2011 8:16 AM, Robert Hamilton wrote:

NetRexxDE is installed and working on a newer laptop(w/ XP SP3) but I have been stymied in trying to install it on an older Desktop(w/ XP SP3).  This was an attempt to interest a local 'For-Profit' school chain in looking at NetRexx.  This is the first time I have been completely unable to deal with any Rexx from ObjRexx on out to NetRexx.  Steve Swift got ooRexx 4.+ running in CGI-BIN on a server at ukservers.net and we had talked about installing NetRexxC also, but there has to be an easier way to deal w/  NetRexx installation .  I'm not giving up on the project but it is in abeyance until NetRexx can be installed on selected PC venues.

Thank you all for the help and enjoy the Day.

Robert L Hamilton, Engineer
Richardson Texas USA   

 

_______________________________________________
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/

[Tom Maynard]

rvjansen <[hidden email]> wrote:

>I would like to take you up on the offer, but officially to
>gather the requirements first.

On which mailing list do you want the inevitable traffic that will ensue?  Perhaps some of the initial requirements gathering can be done here, with a rather wider audience ... but then it should move to -- dev?

I'm currently looking at Scala, Groovy, ..., installers (just for inspiration at this point).  But what is the actual scope of this project?  Win/Lin/Mac certainly, but mainframe too?  Obscure/obsolete OS's as well (Amiga, DOS, ...)?  It can quickly become overwhelming, as you know.

It doesn't seem that any of the JVM language installers I've looked at so far even tries to use a "grand unified installation" tool to fit all platforms.  They typically offer Windows, Mac, and Linux download links ... with some more specialized Linux "flavors" on offer occasionally.  I'm unsure at this point how far to "drill down" for specifics ... and certainly unable to test any mainframe stuff.  It's been a decade or more since I stood next to anything watercooled, and the size of a boxcar ... except my Hummer, of course.

Your input/guidance is most welcome.

Tom


Sent from my Motorola ATRIX™ 4G on AT&T

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Tom -

Thanks for asking the "scope" question.

I have been unwilling to touch this project because I have seen no clear
statement of a goal beyond "NetRexx should be easier to install", much
less seen the actual requirements for the installer. The requirements we
are now seeing are almost overwhelming already, so I would suggest
breaking the project down into more manageable chunks. Perhaps write a
simple installer for one platform that handles the basic cases, then
extend it to more esoteric cases and when that is done, use the
knowledge gained to add support for other platforms. What do you think?

-- Kermit


On 9/23/2011 4:13 PM, Tom Maynard wrote:

> rvjansen<[hidden email]>  wrote:
>
>> I would like to take you up on the offer, but officially to
>> gather the requirements first.
> On which mailing list do you want the inevitable traffic that will ensue?  Perhaps some of the initial requirements gathering can be done here, with a rather wider audience ... but then it should move to -- dev?
>
> I'm currently looking at Scala, Groovy, ..., installers (just for inspiration at this point).  But what is the actual scope of this project?  Win/Lin/Mac certainly, but mainframe too?  Obscure/obsolete OS's as well (Amiga, DOS, ...)?  It can quickly become overwhelming, as you know.
>
> It doesn't seem that any of the JVM language installers I've looked at so far even tries to use a "grand unified installation" tool to fit all platforms.  They typically offer Windows, Mac, and Linux download links ... with some more specialized Linux "flavors" on offer occasionally.  I'm unsure at this point how far to "drill down" for specifics ... and certainly unable to test any mainframe stuff.  It's been a decade or more since I stood next to anything watercooled, and the size of a boxcar ... except my Hummer, of course.
>
> Your input/guidance is most welcome.
>
> Tom
>
>
> Sent from my Motorola ATRIX™ 4G on AT&T
>
> _______________________________________________
> 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/

[alansam]

On 23 September 2011 16:13, Tom Maynard <[hidden email]> wrote:

rvjansen <[hidden email]> wrote:

It doesn't seem that any of the JVM language installers I've looked at so far even tries to use a "grand unified installation" tool to fit all platforms.  They typically offer Windows, Mac, and Linux download links ... with some more specialized Linux "flavors" on offer occasionally.  I'm unsure at this point how far to "drill down" for specifics ... and certainly unable to test any mainframe stuff.  It's been a decade or more since I stood next to anything watercooled, and the size of a boxcar ... except my Hummer, of course.

So long as it's 100% Java, then it will install seamlessly onto Linux guests on z/VM (or even Linux LPARs on bare metal (LPAR is just a glorified z/OS anyway)) and should be no problem on z/OS with UNIX System Services.  I've installed NetRexx on zSeries machines without issue; it just works.  One thing to note though is that in both environments you'd be using IBM's flavor of the JVM as opposed to the Sun/Oracle offering.  Keeping things 100% Java should theoretically allow seamless deployment onto the BSD family (Mac OS X is FreeBSD), AIX, HP-UX, Solaris, etc. too; anywhere there's a JVM.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Fernando Cassia-2]

On Fri, Sep 23, 2011 at 08:55, rvjansen <[hidden email]> wrote:
> When we decide not to have one platform independent installer, there is
> always the way of separate RPM, .dmg, .msi etcetera installers.

That would really, really suck.

There are quite nice Java application installers

http://java-source.net/open-source/installer-generators/izpack
http://java-source.net/open-source/installer-generators/vainstall
FC
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[David Requena]

>> Would it help to introduce some minimal structure into the discussion, say by specifying that issues be reported to a formally named series of threads (Installation Part I, etc with a maximum size) which effectively act as a journal?  Or perhaps Kenai has some mechanism for dealing with this.

Nothing I'm aware of. Perhaps an specific forum? We can have several of these but I've noticed people here tend to dislike them.

-
Saludos / Kind regards,
David Requena

NOTE: The opinions expressed here represent the opinions
of the authors and do not necessarily represent the opinions
of those who hold other opinions.

-----Original Message-----
From: George Hovey <[hidden email]>
Sender: [hidden email]
Date: Fri, 23 Sep 2011 08:46:32
To: IBM Netrexx<[hidden email]>
Reply-To: IBM Netrexx <[hidden email]>
Subject: Re: NetRexx package content, some installer for Windows requirements
        (Re: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
        tools.jar locater algorithm.

_______________________________________________
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/

[George Hovey-2]

David,
Too late -- the discussion is already spread across a number of threads.
George

On Sun, Sep 25, 2011 at 2:58 PM, David Requena <[hidden email]> wrote:

>> Would it help to introduce some minimal structure into the discussion, say by specifying that issues be reported to a formally named series of threads (Installation Part I, etc with a maximum size) which effectively act as a journal?  Or perhaps Kenai has some mechanism for dealing with this.

Nothing I'm aware of. Perhaps an specific forum? We can have several of these but I've noticed people here tend to dislike them.

-
Saludos / Kind regards,
David Requena

NOTE: The opinions expressed here represent the opinions
of the authors and do not necessarily represent the opinions
of those who hold other opinions.

-----Original Message-----
From: George Hovey <[hidden email]>
Sender: [hidden email]
Date: Fri, 23 Sep 2011 08:46:32
To: IBM Netrexx<[hidden email]>
Reply-To: IBM Netrexx <[hidden email]>
Subject: Re: NetRexx package content, some installer for Windows requirements
       (Re: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
       tools.jar locater algorithm.

_______________________________________________
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/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

George Hovey <[hidden email]> wrote:

>Too late -- the discussion is already spread across a number of
>threads.

That may be (and is) very true ... but there is at least one "interested party" out here that has been monitoring all the traffic.  I'm they guy who volunteered to write the NetRexx installer (later modified by Rene to collecting the requirements, at least intially).

I'll summarize everything I've collected over the past few days, and I'll repost my analysis ... what folks seem to want, what they say they need, and what they're currently getting.  And then I'll ask for comments once again, just to make sure I've heard everyone correctly, and that all the voices have been heard.

I'm not sure that anything I've heard in the past few days does anything at all to limit the scope of the project, but let's see what chips I've collected from those that fell, and where they tend to congregate.  But that's tomorrow's task (and maybe the day after, depending).

It's been interesting, to say the least.  Lots of good ideas out there!

Tom.


Sent from my Motorola ATRIX™ 4G on AT&T
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Tom,
I look forward to seeing your analysis, which I expect will be incisive.
George

On Mon, Sep 26, 2011 at 12:12 AM, Tom Maynard <[hidden email]> wrote:

George Hovey <[hidden email]> wrote:

>Too late -- the discussion is already spread across a number of
>threads.

That may be (and is) very true ... but there is at least one "interested party" out here that has been monitoring all the traffic.  I'm they guy who volunteered to write the NetRexx installer (later modified by Rene to collecting the requirements, at least intially).

I'll summarize everything I've collected over the past few days, and I'll repost my analysis ... what folks seem to want, what they say they need, and what they're currently getting.  And then I'll ask for comments once again, just to make sure I've heard everyone correctly, and that all the voices have been heard.

I'm not sure that anything I've heard in the past few days does anything at all to limit the scope of the project, but let's see what chips I've collected from those that fell, and where they tend to congregate.  But that's tomorrow's task (and maybe the day after, depending).

It's been interesting, to say the least.  Lots of good ideas out there!

Tom.


Sent from my Motorola ATRIX™ 4G on AT&T
_______________________________________________

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/

[Robert L Hamilton]

A set of up-to-date instructions would help.  The latest I could find were dated 1/14/2005.

Bob Hamilton
Richardson Texas USA

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/