classpath jedit and netrexx plugin

[KP Kirchdörfer]

Hi;

as Thomas I used the ../jre/lib/ext directory to make additional jars
accessable, and while I understand the implications while moving to a
new JDK, it just worked with NetRexx, jedit and netrexx plugin for jedit.

Today I updated NetRexx to 3.0.2RC and just wanted to "make it right"
once and forever.
As recommended I moved the jar's in question to a neutral place
(/usr/share/NetRexx) ann edited /etc/profile accordingly.
This failed completly for openjdk-6.

No problem to switch to openjdk-7, also a long-term goal, and finally I
can run the classes with the classpath settings in /etc/profile.
(Just wonder, why it doesn't work with openjdk-6...?)

I do NetRexx development with jedit and the NetRexx plugin by Kermit.

First observation: The NetRexx plgin seems to require NetRexxC in
~/.jedit/jars, even though I have set the "Path to NetRexx jar" in the
plugin options to the new place (/usr/share/NetRexx/NetRexxC.jar).

Second observation: jedit does not seem to read the CLASSPATH env,
instead I have to set the classpath in the interpreter tab for the
NetRexx plugin, so it can find the jar's. Took some time to understand
that the settings in "Interpreter" are necessary for the compiler".

And finally: my ant setups to build packages with the jedit ant plugin
are broken. They can't find the classes declared in the CLASSPATH.
Shurely I can modify the build.xml to include the classpath...

... but then, this seems somewhat wrong to me. I'll be save for problems
when moving to a new java version, but I have now to obey classpathes in
/etc/profile, NetRexxs jedit plugin and the ant setup?

I'm pretty shure, I have misssed a step.

Any hints are welcome.

kp

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

[Kermit Kiser]

Hi KP --

It seems that you are mostly using jEdit facilities. There are a few
things that it might help you to know.

The first is that the default jEdit startup sequence uses the "java
-jar" command to run jEdit. Although it is not well known for some
reason, the Java "-jar" operand suppresses all classpath information,
whether environment variable or command line classpath operands. While
jEdit does not actually have to run that way, it is a deliberate choice
by the developers, probably to minimize the possibility of environmental
factors negatively impacting jEdit stability. The consequence of that
choice for NetRexx and other tools running under jEdit is that they have
to obtain classpath information or module locations through some
alternate means, which is why the NetRexx plugin has fields for
specifying classpath data and module locations. (Ant has it's own
facilities for providing classpath info.)

Secondly, the latest NetRexx version is not as sensitive to problems
when running from the Java /lib/ext directory, if you choose that
location for NetRexx or the Java compiler (tools.jar). Of course that
does create the problem you mentioned with new versions of Java losing
track of them. I personally place NetRexx in the jEdit plugin jars
library. A quick module rename and restart of jEdit allows me to test
with a different version of NetRexx that way. The plugin is written in
NetRexx which means that NetRexx must be locatable when it starts and
therefore before any location fields are accessed.

Also, while I have merged the NetRexx interpreter and compiler plugins
for jEdit into one plugin, it is still a first attempt at consolidation.
Most of the compiler and interpreter code is still separate logically
and physically although I have made some attempts to allow the separate
classpath mechanisms to apply in both modes. That may be a source of
confusion, however.

I hope that clarifies some of the issues.

-- Kermit


On 4/21/2013 5:18 AM, KP Kirchdörfer wrote:

> Hi;
>
> as Thomas I used the ../jre/lib/ext directory to make additional jars
> accessable, and while I understand the implications while moving to a
> new JDK, it just worked with NetRexx, jedit and netrexx plugin for jedit.
>
> Today I updated NetRexx to 3.0.2RC and just wanted to "make it right"
> once and forever.
> As recommended I moved the jar's in question to a neutral place
> (/usr/share/NetRexx) ann edited /etc/profile accordingly.
> This failed completly for openjdk-6.
>
> No problem to switch to openjdk-7, also a long-term goal, and finally I
> can run the classes with the classpath settings in /etc/profile.
> (Just wonder, why it doesn't work with openjdk-6...?)
>
> I do NetRexx development with jedit and the NetRexx plugin by Kermit.
>
> First observation: The NetRexx plgin seems to require NetRexxC in
> ~/.jedit/jars, even though I have set the "Path to NetRexx jar" in the
> plugin options to the new place (/usr/share/NetRexx/NetRexxC.jar).
>
> Second observation: jedit does not seem to read the CLASSPATH env,
> instead I have to set the classpath in the interpreter tab for the
> NetRexx plugin, so it can find the jar's. Took some time to understand
> that the settings in "Interpreter" are necessary for the compiler".
>
> And finally: my ant setups to build packages with the jedit ant plugin
> are broken. They can't find the classes declared in the CLASSPATH.
> Shurely I can modify the build.xml to include the classpath...
>
> ... but then, this seems somewhat wrong to me. I'll be save for problems
> when moving to a new java version, but I have now to obey classpathes in
> /etc/profile, NetRexxs jedit plugin and the ant setup?
>
> I'm pretty shure, I have misssed a step.
>
> Any hints are welcome.
>
> kp
>
> _______________________________________________
> 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)]

... cut ...

On 25.04.2013 06:42, Kermit Kiser wrote:
> Secondly, the latest NetRexx version is not as sensitive to problems when running from the Java
> /lib/ext directory, if you choose that location for NetRexx or the Java compiler (tools.jar). Of
> course that does create the problem you mentioned with new versions of Java losing track of them.
> I personally place NetRexx in the jEdit plugin jars library.
... cut ...

Just a little hint w.r.t. the Java extension directory: depending on the baseline for Java one is
able to place extensions in a user-relative extension directory, such that updates or upgrades of
Java won't lose access to it. Just inspect the Java property named "java.ext.dirs" to learn about
this directory.

HTH,

---rony

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

[Tom Maynard]

On 25-Apr-13 08:55, Rony wrote:

Just a little hint...inspect the Java property named "java.ext.dirs" to learn about
this directory.

To add a bit to Rony's excellent suggestion, while doing your inspection be sure to look carefully at Java's class path wildcards ("*").  Refer (for both suggestions) to Oracle's doc page.

Perhaps we need to establish a "NetRexx best practices" standard somewhere, a standard that could be implemented in the NetRexx installer.


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

[KP Kirchdörfer]

Hi;

thanx for responding.

Am 25.04.2013 06:42, schrieb Kermit Kiser:
> Hi KP --
>
> It seems that you are mostly using jEdit facilities. There are a few
> things that it might help you to know.

> The first is that the default jEdit startup sequence uses the "java
> -jar" command to run jEdit. Although it is not well known for some
> reason, the Java "-jar" operand suppresses all classpath information,
> whether environment variable or command line classpath operands. While
> jEdit does not actually have to run that way, it is a deliberate choice
> by the developers, probably to minimize the possibility of environmental
> factors negatively impacting jEdit stability. The consequence of that
> choice for NetRexx and other tools running under jEdit is that they have
> to obtain classpath information or module locations through some
> alternate means, which is why the NetRexx plugin has fields for
> specifying classpath data and module locations. (Ant has it's own
> facilities for providing classpath info.)

Understand.

I've not found another way to tell ant/antelope to get the jar files
than using lib/ext.
(java.ext.dirs are shown in the antelope settings, but I don't know how
to change)

After I've spent a few days testing various classpath settings, even
rebooting the machine, reinstalling ant etc etc, I've reverted my setup
to still use the extension directory (and to ignore the recommended
way), it's a lot easier to copy files from java6 lib/ext to java7
lib/ext than to change things here and there. Maybe I should have spent
my time to investigate if links would be enough, and if not to write a
small shell script to update lib/ext whenever I install a new major java
version.

After a few days of work, I do believe putting additional jars into
lib/ext is really easy compared to using my own classpath.

Todo's now are:
clean up the the mess of the testing and test again
remove classpath setings from .profile
get antelope plugin for jedit to work again (maybe an issue related to
switching java from 1.6 to 1.7)


I do understand why Thomas insist on lib/ext, though I've learned a few
things about my development environment, as usual :)

> Secondly, the latest NetRexx version is not as sensitive to problems
> when running from the Java /lib/ext directory, if you choose that
> location for NetRexx or the Java compiler (tools.jar). Of course that
> does create the problem you mentioned with new versions of Java losing
> track of them. I personally place NetRexx in the jEdit plugin jars
> library. A quick module rename and restart of jEdit allows me to test
> with a different version of NetRexx that way. The plugin is written in
> NetRexx which means that NetRexx must be locatable when it starts and
> therefore before any location fields are accessed.

Understand

> Also, while I have merged the NetRexx interpreter and compiler plugins
> for jEdit into one plugin, it is still a first attempt at consolidation.
> Most of the compiler and interpreter code is still separate logically
> and physically although I have made some attempts to allow the separate
> classpath mechanisms to apply in both modes. That may be a source of
> confusion, however.
>
> I hope that clarifies some of the issues.

Thx a lot for the NetRexx plugin, it does help a lot!

kp

> -- Kermit
>
>
> On 4/21/2013 5:18 AM, KP Kirchdörfer wrote:
>> Hi;
>>
>> as Thomas I used the ../jre/lib/ext directory to make additional jars
>> accessable, and while I understand the implications while moving to a
>> new JDK, it just worked with NetRexx, jedit and netrexx plugin for jedit.
>>
>> Today I updated NetRexx to 3.0.2RC and just wanted to "make it right"
>> once and forever.
>> As recommended I moved the jar's in question to a neutral place
>> (/usr/share/NetRexx) ann edited /etc/profile accordingly.
>> This failed completly for openjdk-6.
>>
>> No problem to switch to openjdk-7, also a long-term goal, and finally I
>> can run the classes with the classpath settings in /etc/profile.
>> (Just wonder, why it doesn't work with openjdk-6...?)
>>
>> I do NetRexx development with jedit and the NetRexx plugin by Kermit.
>>
>> First observation: The NetRexx plgin seems to require NetRexxC in
>> ~/.jedit/jars, even though I have set the "Path to NetRexx jar" in the
>> plugin options to the new place (/usr/share/NetRexx/NetRexxC.jar).
>>
>> Second observation: jedit does not seem to read the CLASSPATH env,
>> instead I have to set the classpath in the interpreter tab for the
>> NetRexx plugin, so it can find the jar's. Took some time to understand
>> that the settings in "Interpreter" are necessary for the compiler".
>>
>> And finally: my ant setups to build packages with the jedit ant plugin
>> are broken. They can't find the classes declared in the CLASSPATH.
>> Shurely I can modify the build.xml to include the classpath...
>>
>> ... but then, this seems somewhat wrong to me. I'll be save for problems
>> when moving to a new java version, but I have now to obey classpathes in
>> /etc/profile, NetRexxs jedit plugin and the ant setup?
>>
>> I'm pretty shure, I have misssed a step.
>>
>> Any hints are welcome.
>>
>> kp
>>
>> _______________________________________________
>> 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/

[KP Kirchdörfer]

To respond to myself...


Switching back was easy now that I've added all the stuff back to lib/ext.
even antelope worked after reboot.


An remaining minor issue is that I see

"Path to NetRexxC.jar not valid.
User global options.plugin.options.netrexxde to set this manually"

How to get rid of this?

TIA kp

Am 25.04.2013 20:38, schrieb KP Kirchdörfer:

> Hi;
>
> thanx for responding.
>
> Am 25.04.2013 06:42, schrieb Kermit Kiser:
>> Hi KP --
>>
>> It seems that you are mostly using jEdit facilities. There are a few
>> things that it might help you to know.
>
>> The first is that the default jEdit startup sequence uses the "java
>> -jar" command to run jEdit. Although it is not well known for some
>> reason, the Java "-jar" operand suppresses all classpath information,
>> whether environment variable or command line classpath operands. While
>> jEdit does not actually have to run that way, it is a deliberate choice
>> by the developers, probably to minimize the possibility of environmental
>> factors negatively impacting jEdit stability. The consequence of that
>> choice for NetRexx and other tools running under jEdit is that they have
>> to obtain classpath information or module locations through some
>> alternate means, which is why the NetRexx plugin has fields for
>> specifying classpath data and module locations. (Ant has it's own
>> facilities for providing classpath info.)
>
> Understand.
>
> I've not found another way to tell ant/antelope to get the jar files
> than using lib/ext.
> (java.ext.dirs are shown in the antelope settings, but I don't know how
> to change)
>
> After I've spent a few days testing various classpath settings, even
> rebooting the machine, reinstalling ant etc etc, I've reverted my setup
> to still use the extension directory (and to ignore the recommended
> way), it's a lot easier to copy files from java6 lib/ext to java7
> lib/ext than to change things here and there. Maybe I should have spent
> my time to investigate if links would be enough, and if not to write a
> small shell script to update lib/ext whenever I install a new major java
> version.
>
> After a few days of work, I do believe putting additional jars into
> lib/ext is really easy compared to using my own classpath.
>
> Todo's now are:
> clean up the the mess of the testing and test again
> remove classpath setings from .profile
> get antelope plugin for jedit to work again (maybe an issue related to
> switching java from 1.6 to 1.7)
>
>
> I do understand why Thomas insist on lib/ext, though I've learned a few
> things about my development environment, as usual :)
>
>> Secondly, the latest NetRexx version is not as sensitive to problems
>> when running from the Java /lib/ext directory, if you choose that
>> location for NetRexx or the Java compiler (tools.jar). Of course that
>> does create the problem you mentioned with new versions of Java losing
>> track of them. I personally place NetRexx in the jEdit plugin jars
>> library. A quick module rename and restart of jEdit allows me to test
>> with a different version of NetRexx that way. The plugin is written in
>> NetRexx which means that NetRexx must be locatable when it starts and
>> therefore before any location fields are accessed.
>
> Understand
>
>> Also, while I have merged the NetRexx interpreter and compiler plugins
>> for jEdit into one plugin, it is still a first attempt at consolidation.
>> Most of the compiler and interpreter code is still separate logically
>> and physically although I have made some attempts to allow the separate
>> classpath mechanisms to apply in both modes. That may be a source of
>> confusion, however.
>>
>> I hope that clarifies some of the issues.
>
> Thx a lot for the NetRexx plugin, it does help a lot!
>
> kp
>
>> -- Kermit
>>
>>
>> On 4/21/2013 5:18 AM, KP Kirchdörfer wrote:
>>> Hi;
>>>
>>> as Thomas I used the ../jre/lib/ext directory to make additional jars
>>> accessable, and while I understand the implications while moving to a
>>> new JDK, it just worked with NetRexx, jedit and netrexx plugin for jedit.
>>>
>>> Today I updated NetRexx to 3.0.2RC and just wanted to "make it right"
>>> once and forever.
>>> As recommended I moved the jar's in question to a neutral place
>>> (/usr/share/NetRexx) ann edited /etc/profile accordingly.
>>> This failed completly for openjdk-6.
>>>
>>> No problem to switch to openjdk-7, also a long-term goal, and finally I
>>> can run the classes with the classpath settings in /etc/profile.
>>> (Just wonder, why it doesn't work with openjdk-6...?)
>>>
>>> I do NetRexx development with jedit and the NetRexx plugin by Kermit.
>>>
>>> First observation: The NetRexx plgin seems to require NetRexxC in
>>> ~/.jedit/jars, even though I have set the "Path to NetRexx jar" in the
>>> plugin options to the new place (/usr/share/NetRexx/NetRexxC.jar).
>>>
>>> Second observation: jedit does not seem to read the CLASSPATH env,
>>> instead I have to set the classpath in the interpreter tab for the
>>> NetRexx plugin, so it can find the jar's. Took some time to understand
>>> that the settings in "Interpreter" are necessary for the compiler".
>>>
>>> And finally: my ant setups to build packages with the jedit ant plugin
>>> are broken. They can't find the classes declared in the CLASSPATH.
>>> Shurely I can modify the build.xml to include the classpath...
>>>
>>> ... but then, this seems somewhat wrong to me. I'll be save for problems
>>> when moving to a new java version, but I have now to obey classpathes in
>>> /etc/profile, NetRexxs jedit plugin and the ant setup?
>>>
>>> I'm pretty shure, I have misssed a step.
>>>
>>> Any hints are welcome.
>>>
>>> kp
>>>
>>> _______________________________________________
>>> 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/

[ThSITC]

Thanks for this specific URL, Tom!

Happy Weekend, all!

PS: we do have very sunny weather here, nowadays, in Vienna, with some 29  ° Celsius, which seem to be 83 ° Fahrenheit, accourding to my double Thermometer ;-)
=====================================================================================
Am 25.04.2013 16:58, schrieb Tom Maynard:

On 25-Apr-13 08:55, Rony wrote:

Just a little hint...inspect the Java property named "java.ext.dirs" to learn about
this directory.

To add a bit to Rony's excellent suggestion, while doing your inspection be sure to look carefully at Java's class path wildcards ("*").  Refer (for both suggestions) to Oracle's doc page.

Perhaps we need to establish a "NetRexx best practices" standard somewhere, a standard that could be implemented in the NetRexx installer.

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

[ThSITC]

Thanks for this hint, RONY, as well, didn't know (working alone here,
sorry ...)
Thomas.
=============================================================

Am 25.04.2013 15:55, schrieb Rony:

> ... cut ...
>
> On 25.04.2013 06:42, Kermit Kiser wrote:
>> Secondly, the latest NetRexx version is not as sensitive to problems when running from the Java
>> /lib/ext directory, if you choose that location for NetRexx or the Java compiler (tools.jar). Of
>> course that does create the problem you mentioned with new versions of Java losing track of them.
>> I personally place NetRexx in the jEdit plugin jars library.
> ... cut ...
>
> Just a little hint w.r.t. the Java extension directory: depending on the baseline for Java one is
> able to place extensions in a user-relative extension directory, such that updates or upgrades of
> Java won't lose access to it. Just inspect the Java property named "java.ext.dirs" to learn about
> this directory.
>
> HTH,
>
> ---rony
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria,
Europe

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