Including *another* .jar file in MY .jar file
Locked
12
12
Including *another* .jar file in MY .jar file
 
|
Hello there, (primarily for Rene, David, and Kermit, and Chip, but copy
to the group for info) I'm using a special BUILD mechanism for my current ReyC release, and would like to *have* ***NOT***, repeat NOT, the need to have sooo many Jar's on my system. Questions: 1.) Is there a (documented) method to *include* another JAR (as for Instance, NetRexxDE and/or NetRexxScript, NetRexxC) during my build in my Jar (namely: ReyC.jar) ? :-) 2.) Do you recommend this? ;-) Frankly speaking, I would like to have to *not* to maintain sooo many entries in my classpath. I would like to have a *concerted* approach, where the *simple* novice does have *only* to add 1 bit in his environment (and thus ONE environment Home-variable, in my case it is ReyHome) to get all those *nice* utilities we're working on at once.... When you are looking at the REXXLA correspondace, you see, how many people are overwhelmed for what they have to do to somply get NetRexx running .... :-( What do you think ? Tom.
Tom. (ths@db-123.com)
|
Including *another* .jar file in MY .jar file
|
|
Thomas;
There is no mechanism in Java to nest Jar files. You would have to write a rather tricky classloader to handle it and it would only have limited use as no other code would know how to use it. (I looked into this once myself.) There are two possible ways I can think of to handle the problem: 1) Make your application dependent on Java 1.6 or higher. Then put all the Jar files in a single directory. Java 1.6 allows a wildcard jar specification in your classpaths which makes an easy way to pick up all jars in a directory: Something like this should work: CLASSPATH=C:\jardirectory\* This also works with the "- classpath" command line option which is the preferred approach. Look here for more info on classpath wildcards: http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html 2) You can also unzip all of the required Jar files and then create a new Jar file which contains all of the directories and files that were in the separate Jar files. Kermit Thomas Schneider wrote: > Hello there, (primarily for Rene, David, and Kermit, and Chip, but > copy to the group for info) > > I'm using a special BUILD mechanism for my current ReyC release, and > would like to > *have* ***NOT***, repeat NOT, the need to have sooo many Jar's on > my system. > > Questions: > > 1.) Is there a (documented) method to *include* another JAR (as for > Instance, NetRexxDE > and/or NetRexxScript, NetRexxC) during my build in my Jar (namely: > ReyC.jar) ? :-) > > 2.) Do you recommend this? ;-) > > Frankly speaking, I would like to have to *not* to maintain sooo many > entries in my classpath. > > I would like to have a *concerted* approach, where the *simple* novice > does have *only* to add 1 bit > in his environment (and thus ONE environment Home-variable, in my case > it is ReyHome) > > to get all those *nice* utilities we're working on at once.... > > When you are looking at the REXXLA correspondace, you see, how many > people are > overwhelmed for what they have to do to somply get NetRexx running > .... :-( > > What do you think ? > > Tom. > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > |
Including *another* .jar file in MY .jar file
|
|
Hello Kermit, I'm still alive, by the way.....
Frankly speaking, I would like (with Rene's, David's, and yours *approval* to have one, and only one, *delivering* ****.JAR**** For the time beeing, I am thinking of that Rey (Rexx for Java) might be a *new*, short, Brand name.... But this are my personal feeling, of course, only. I would like, whenever possible, to include MARK Hessling in this discussion. Mark is the Author of SOOOO many REXX tool's. And Mark has, as far as I do know, the only *current* *classic REXX LA compliant* implementation on hand. ... When Mark and I ould colleborate *on a JOINT Effort* ... to use his REGINA SOURCE as a *BETA Test-Case* for *ReyC* Then the whole System (ReyC: The Rexx for Java Compiler) will be *for sure* :-) FOOL-Prove !!!! Tom. Kermit Kiser schrieb: > Thomas; > > There is no mechanism in Java to nest Jar files. You would have to > write a rather tricky classloader to handle it and it would only have > limited use as no other code would know how to use it. (I looked into > this once myself.) > > There are two possible ways I can think of to handle the problem: > > 1) Make your application dependent on Java 1.6 or higher. Then put all > the Jar files in a single directory. Java 1.6 allows a wildcard jar > specification in your classpaths which makes an easy way to pick up > all jars in a directory: > > Something like this should work: > > CLASSPATH=C:\jardirectory\* > > This also works with the "- classpath" command line option which is > the preferred approach. Look here for more info on classpath wildcards: > > http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html > > > 2) You can also unzip all of the required Jar files and then create a > new Jar file which contains all of the directories and files that were > in the separate Jar files. > > Kermit > > > > Thomas Schneider wrote: >> Hello there, (primarily for Rene, David, and Kermit, and Chip, but >> copy to the group for info) >> >> I'm using a special BUILD mechanism for my current ReyC release, and >> would like to >> *have* ***NOT***, repeat NOT, the need to have sooo many Jar's on >> my system. >> >> Questions: >> >> 1.) Is there a (documented) method to *include* another JAR (as for >> Instance, NetRexxDE >> and/or NetRexxScript, NetRexxC) during my build in my Jar (namely: >> ReyC.jar) ? :-) >> >> 2.) Do you recommend this? ;-) >> >> Frankly speaking, I would like to have to *not* to maintain sooo many >> entries in my classpath. >> >> I would like to have a *concerted* approach, where the *simple* >> novice does have *only* to add 1 bit >> in his environment (and thus ONE environment Home-variable, in my >> case it is ReyHome) >> >> to get all those *nice* utilities we're working on at once.... >> >> When you are looking at the REXXLA correspondace, you see, how many >> people are >> overwhelmed for what they have to do to somply get NetRexx running >> .... :-( >> >> What do you think ? >> >> Tom. >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > >
Tom. (ths@db-123.com)
|
|
In reply to this post by Kermit Kiser
On 17 February 2010 19:10, Kermit Kiser <[hidden email]> wrote:
> > > 1) Make your application dependent on Java 1.6 or higher. Then put all the > Jar files in a single directory. Java 1.6 allows a wildcard jar > specification in your classpaths which makes an easy way to pick up all jars > in a directory: > > Something like this should work: > > CLASSPATH=C:\jardirectory\* > > This also works with the "- classpath" command line option which is the > preferred approach. Look here for more info on classpath wildcards: > > http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html > > Kermit > > Maven (at http://maven.apache.org/) projects as a means of building your distribution package. I've used Ant both stand-alone and inside Eclipse to generate target jar files then build distribution packages that include all the referenced jar files, shell scripts, property files, XML, images, web pages etc. with everything in their correct places in a run-time directory hierarchy then roll the whole bundle into tarballs and zip files. The nice thing about Ant is is it makes the build/package process both repeatable and predictable. (I haven't tried but I suspect you could even coerce Ant to compile NetRexx programs for you.) Alan. -- Needs more cow-bell! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100217/00034be5/attachment.html
Alan
-- Needs more cowbell. |
Including *another* .jar file in MY .jar file
|
|
In reply to this post by Kermit Kiser
On Thu, Feb 18, 2010 at 12:10 AM, Kermit Kiser <[hidden email]> wrote:
> Thomas; > > There is no mechanism in Java to nest Jar files. You would have to write a > rather tricky classloader to handle it and it would only have limited use as > no other code would know how to use it. (I looked into this once myself.) > > There are two possible ways I can think of to handle the problem: > > 1) Make your application dependent on Java 1.6 or higher. Then put all the > Jar files in a single directory. Java 1.6 allows a wildcard jar > specification in your classpaths which makes an easy way to pick up all jars > in a directory: > > Something like this should work: > > CLASSPATH=C:\jardirectory\* > > This also works with the "- classpath" command line option which is the > preferred approach. Look here for more info on classpath wildcards: > > http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html > > > 2) You can also unzip all of the required Jar files and then create a new > Jar file which contains all of the directories and files that were in the > separate Jar files. > > Kermit I never had to "configure the classpath" or change the classpath while running Java applications since the Java 1.x days. After Java2 (java 1.2.x onwards) every decently coded app I?ve run is able to run using java -jar appname.jar Without doing any extra configuration or change to my system. Take Java Image Editor, for instance... http://www.jhlabs.com/ie/ I use it daily. The key for "Java -jar" enabling of an application is adding the Main-Class: classname parameter to the "manifest" http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html I?m sorry if I misunderstood your question... FC |
Including *another* .jar file in MY .jar file
|
|
In reply to this post by alansam
Hello Alan,
I *did* (with some minor problems) *update* my machines to NetRexxC 2.05 and Java 1.6.18 What I am, for the minute, *seeking for* is: To integrate all those marvelous NetRexx *tools*, like Kemit Kiser's NetRexxScript, and David Requenas NetRexxDE, and NetRexxC (vs. 2.05) (and my Rey Compiler, of course), in a single JAR File (in my case: ReyC.jar), *once forever*. By the way, I did now manage to install all those marvelous NetRexx tool's on my machine.... ... still testing, sorry to say ;-) Tom. ========================================================================== Alan Sampson schrieb: > > > On 17 February 2010 19:10, Kermit Kiser <[hidden email] > <mailto:[hidden email]>> wrote: > > > > 1) Make your application dependent on Java 1.6 or higher. Then put > all the Jar files in a single directory. Java 1.6 allows a > wildcard jar specification in your classpaths which makes an easy > way to pick up all jars in a directory: > > Something like this should work: > > CLASSPATH=C:\jardirectory\* > > This also works with the "- classpath" command line option which > is the preferred approach. Look here for more info on classpath > wildcards: > > http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html > > Kermit > > > You should take a look at the Apache Ant (at http://ant.apache.org/) > or Maven (at http://maven.apache.org/) projects as a means of building > your distribution package. I've used Ant both stand-alone and inside > Eclipse to generate target jar files then build distribution packages > that include all the referenced jar files, shell scripts, property > files, XML, images, web pages etc. with everything in their correct > places in a run-time directory hierarchy then roll the whole bundle > into tarballs and zip files. > > The nice thing about Ant is is it makes the build/package process both > repeatable and predictable. > > (I haven't tried but I suspect you could even coerce Ant to compile > NetRexx programs for you.) > > Alan. > > -- > Needs more cow-bell! > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > >
Tom. (ths@db-123.com)
|
Including *another* .jar file in MY .jar file
|
|
In reply to this post by Fernando Cassia-2
Hi gents....
I do *know*, that I Can UNZIP *all* those classes involved, to my proper sub-directories.... I am NO novice.... That's exactly what I did on my machine..... I added all those tools to my Rey.jar ... sorry to say.... And I'm currenntly testing alll of this on my machine ..... (With my Rey.jar) I#m only preculiar *if this will be* an accepted solution: Rey ::= Rexx for Java (including anything needed). Tom. ========================================================= = Fernando Cassia schrieb: > On Thu, Feb 18, 2010 at 12:10 AM, Kermit Kiser <[hidden email]> wrote: > >> Thomas; >> >> There is no mechanism in Java to nest Jar files. You would have to write a >> rather tricky classloader to handle it and it would only have limited use as >> no other code would know how to use it. (I looked into this once myself.) >> >> There are two possible ways I can think of to handle the problem: >> >> 1) Make your application dependent on Java 1.6 or higher. Then put all the >> Jar files in a single directory. Java 1.6 allows a wildcard jar >> specification in your classpaths which makes an easy way to pick up all jars >> in a directory: >> >> Something like this should work: >> >> CLASSPATH=C:\jardirectory\* >> >> This also works with the "- classpath" command line option which is the >> preferred approach. Look here for more info on classpath wildcards: >> >> http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html >> >> >> 2) You can also unzip all of the required Jar files and then create a new >> Jar file which contains all of the directories and files that were in the >> separate Jar files. >> >> Kermit >> > > I never had to "configure the classpath" or change the classpath while > running Java applications since the Java 1.x days. > > After Java2 (java 1.2.x onwards) every decently coded app I?ve run is > able to run using > > java -jar appname.jar > > Without doing any extra configuration or change to my system. > > Take Java Image Editor, for instance... > http://www.jhlabs.com/ie/ > > I use it daily. > > The key for "Java -jar" enabling of an application is adding the > Main-Class: classname > parameter to the "manifest" > > http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html > > I?m sorry if I misunderstood your question... > FC > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > >
Tom. (ths@db-123.com)
|
Including *another* .jar file in MY .jar file
|
|
In reply to this post by Fernando Cassia-2
Hi Fernando,
I'm currently working here in Vienna, Austria, to release Rey ::== Rexx for Java. Rey is a new *acronym* I did invent for :: Rexx for Java. Frankly speaking, I'm trying to get my Rey Compiler working. And I will desperatily need some BETA Test sites. Rey, by DESIGN is: a) classic IBM Rexx Compiler compatible (as www.Rexx2Nrx.com, see Examples, has been some 8-9 years ago ....) b) NetRexx Compatible- I will try, anyway, to complete my Chop (ReyC: The Rey Compiler) but what I did want to do is to: Introduce Rey: (as a new brand name: Rexx for Java) Sorry you all, to interrupt you again . :-) Thomas. Fernando Cassia schrieb: > On Thu, Feb 18, 2010 at 12:10 AM, Kermit Kiser <[hidden email]> wrote: > >> Thomas; >> >> There is no mechanism in Java to nest Jar files. You would have to write a >> rather tricky classloader to handle it and it would only have limited use as >> no other code would know how to use it. (I looked into this once myself.) >> >> There are two possible ways I can think of to handle the problem: >> >> 1) Make your application dependent on Java 1.6 or higher. Then put all the >> Jar files in a single directory. Java 1.6 allows a wildcard jar >> specification in your classpaths which makes an easy way to pick up all jars >> in a directory: >> >> Something like this should work: >> >> CLASSPATH=C:\jardirectory\* >> >> This also works with the "- classpath" command line option which is the >> preferred approach. Look here for more info on classpath wildcards: >> >> http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html >> >> >> 2) You can also unzip all of the required Jar files and then create a new >> Jar file which contains all of the directories and files that were in the >> separate Jar files. >> >> Kermit >> > > I never had to "configure the classpath" or change the classpath while > running Java applications since the Java 1.x days. > > After Java2 (java 1.2.x onwards) every decently coded app I?ve run is > able to run using > > java -jar appname.jar > > Without doing any extra configuration or change to my system. > > Take Java Image Editor, for instance... > http://www.jhlabs.com/ie/ > > I use it daily. > > The key for "Java -jar" enabling of an application is adding the > Main-Class: classname > parameter to the "manifest" > > http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html > > I?m sorry if I misunderstood your question... > FC > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > >
Tom. (ths@db-123.com)
|
Including *another* .jar file in MY .jar file
|
|
In reply to this post by Fernando Cassia-2
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100218/0bceebd6/attachment.html
Tom. (ths@db-123.com)
|
Including *another* .jar file in MY .jar file
|
|
On Thu, Feb 18, 2010 at 3:10 AM, Thomas Schneider <[hidden email]> wrote:
> As Mike is (or has) retired as an IBM Fellow...... > > May it be Not the time to invent some *new name* ??? > > Tom. > Whatever name you choose is fine by me. Is R4J or RxJA (pronounced Rexx-Ja!) already taken?. :) In my dream world, I would like to be able to write pieces of code in procedural Rexx, other pieces of code in procedural Basic, and other pieces of code in JavaFX.... and it all would work seamlessly compiled as Java bytecode ... in a Java VM... :-) Now if I could only convince Oracle?s Larry Ellison to bring Sun?s Project Semplice (compiling Visual Basic source code to Java Bytecode) back to life..... http://www.facebook.com/group.php?gid=56023420682 ;-) FC PS: I must be the King of Fighting Lost Battles.... ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100218/c61a7dda/attachment.html |
Including *another* .jar file in MY .jar file
|
|
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100218/4210c79d/attachment.html
Tom. (ths@db-123.com)
|
Re: [Ibm-netrexx] Including *another* .jar file in MY .jar file
|
|
In reply to this post by alansam
Alan,
> You should take a look at the Apache Ant (at http://ant.apache.org/) > or Maven (at http://maven.apache.org/) projects as a means of building > your distribution package. I've used Ant both stand-alone and inside > Eclipse to generate target jar files then build distribution packages > that include all the referenced jar files, shell scripts, property > files, XML, images, web pages etc. with everything in their correct > places in a run-time directory hierarchy then roll the whole bundle > into tarballs and zip files. > > The nice thing about Ant is is it makes the build/package process both > repeatable and predictable. > Totally agree, that is in fact how NetRexxDE is built. > (I haven't tried but I suspect you could even coerce Ant to compile > NetRexx programs for you.) > There is an optional ant task for this purpose. Find below how I'm using it in NetRexxDE. I'm posting the whole target def it shows how I workaround an issue this netrexx-task has with path separator handling. <target name="compile" depends="-init"> <!-- NetRexx task should handle the classpath nested element on its own or, at least, properly convert the path separator in its classpath attribute to the platform's one. In the meantime we'll use the ${toString:path} trick --> <path id="netrexxc.classpath"> <pathelement location="${jedit.install.dir}/jedit.jar"/> <pathelement location="${project.src.dir}"/> <fileset dir="${jedit.jars.directory}"> <include name="NetRexxC.jar"/> <include name="ErrorList.jar"/> <include name="CommonControls.jar"/> <include name="SideKick.jar"/> <include name="ProjectViewer.jar"/> <include name="jh.jar"/> </fileset> </path> <netrexxc srcdir="${project.src.dir}" destdir="${project.build.dir}" crossref="false" replace="true" classpath="${toString:netrexxc.classpath}"> </netrexxc> </target> _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: [Ibm-netrexx] Including *another* .jar file in MY .jar file
|
|
In reply to this post by Thomas.Schneider.Wien
Thomas,
NetRexxDE is a jEdit plugin. Everything in it is coded to interface in some way to services ofered by jEdit or by other plugins. It can't even run standalone as its tightly tied to jEdit's user interface. I fail to see how bundling it to other non jEdit related software would benefit anyone. --- Saludos / Kind regards. David Requena El 18/02/2010 5:35, Thomas Schneider escribió: > Hello Alan, > I *did* (with some minor problems) *update* my machines to NetRexxC > 2.05 and Java 1.6.18 > > What I am, for the minute, *seeking for* is: > > To integrate all those marvelous NetRexx *tools*, like Kemit Kiser's > NetRexxScript, and David Requenas > NetRexxDE, and NetRexxC (vs. 2.05) (and my Rey Compiler, of course), > in a single > JAR File (in my case: ReyC.jar), > > *once forever*. > > By the way, I did now manage to install all those marvelous NetRexx > tool's on my machine.... > > ... still testing, sorry to say ;-) > Tom. > ========================================================================== > > > > Alan Sampson schrieb: >> >> >> On 17 February 2010 19:10, Kermit Kiser <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> >> >> 1) Make your application dependent on Java 1.6 or higher. Then put >> all the Jar files in a single directory. Java 1.6 allows a >> wildcard jar specification in your classpaths which makes an easy >> way to pick up all jars in a directory: >> >> Something like this should work: >> >> CLASSPATH=C:\jardirectory\* >> >> This also works with the "- classpath" command line option which >> is the preferred approach. Look here for more info on classpath >> wildcards: >> >> >> http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html >> >> Kermit >> >> >> You should take a look at the Apache Ant (at http://ant.apache.org/) >> or Maven (at http://maven.apache.org/) projects as a means of >> building your distribution package. I've used Ant both stand-alone >> and inside Eclipse to generate target jar files then build >> distribution packages that include all the referenced jar files, >> shell scripts, property files, XML, images, web pages etc. with >> everything in their correct places in a run-time directory hierarchy >> then roll the whole bundle into tarballs and zip files. >> >> The nice thing about Ant is is it makes the build/package process >> both repeatable and predictable. >> >> (I haven't tried but I suspect you could even coerce Ant to compile >> NetRexx programs for you.) >> >> Alan. >> >> -- >> Needs more cow-bell! >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Ibm-netrexx mailing list [hidden email] |
Re: Including *another* .jar file in MY .jar file
|
|
In reply to this post by David Requena
David ;
I also use Ant for building my NetRexx projects. I am a little puzzled by your example though - I have not had to use the "toString" trick at all, although I did have to use the ${path.separator} property to allow my classpaths to work on both Windows and Unix systems (which is odd since using "/" for file.separator seems to work on both.): ------------------------------------------------------------------------------------------------------------- <target name="buildnrx" depends="compileJava" description="Compiles NetRexx source files"> <netrexxc srcDir="src" destDir="." includes="*.nrx" classpath=".${path.separator}${project.netrexx.libdir}/NetRexxC.jar${path.separator}${jedit.install.dir}/jedit.jar${path.separator}${jedit.plugins.dir}/ErrorList.jar" comments="false" savelog="false" time="true" compact="false" verbose='verbose0' crossref="false" replace="false" keep="false"/> </target> ------------------------------------------------------------------------------------------------------------- Why do you need the toString trick? Is the "path.separator" property not very well known? I wonder if the classpath wildcard is supported in Ant now? -- Kermit David Requena wrote: > Alan, > >> You should take a look at the Apache Ant (at http://ant.apache.org/) >> or Maven (at http://maven.apache.org/) projects as a means of >> building your distribution package. I've used Ant both stand-alone >> and inside Eclipse to generate target jar files then build >> distribution packages that include all the referenced jar files, >> shell scripts, property files, XML, images, web pages etc. with >> everything in their correct places in a run-time directory hierarchy >> then roll the whole bundle into tarballs and zip files. >> >> The nice thing about Ant is is it makes the build/package process >> both repeatable and predictable. >> > > Totally agree, that is in fact how NetRexxDE is built. > >> (I haven't tried but I suspect you could even coerce Ant to compile >> NetRexx programs for you.) >> > > There is an optional ant task for this purpose. Find below how I'm > using it in NetRexxDE. I'm posting the whole target def it shows how I > workaround an issue this netrexx-task has with path separator handling. > > <target name="compile" depends="-init"> > <!-- NetRexx task should handle the classpath nested element > on its own or, at least, properly convert the path separator > in its classpath attribute to the platform's one. In the > meantime we'll use the ${toString:path} trick > --> > <path id="netrexxc.classpath"> > <pathelement location="${jedit.install.dir}/jedit.jar"/> > <pathelement location="${project.src.dir}"/> > <fileset dir="${jedit.jars.directory}"> > <include name="NetRexxC.jar"/> > <include name="ErrorList.jar"/> > <include name="CommonControls.jar"/> > <include name="SideKick.jar"/> > <include name="ProjectViewer.jar"/> > <include name="jh.jar"/> > </fileset> > </path> > <netrexxc srcdir="${project.src.dir}" destdir="${project.build.dir}" > crossref="false" > replace="true" > classpath="${toString:netrexxc.classpath}"> > </netrexxc> > </target> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > Ibm-netrexx mailing list [hidden email] |
Re: Including *another* .jar file in MY .jar file
|
|
Kermit,
You're building a classpath string 'by hand'. Customarily ant tasks taking a classpath do accept either: - a string with '/' as a path separator, then adapting this to the platform's actual path separator at runtime. - a '<path> construct with nested <patelement>, <fileset>, etc., then handling the platform stuff internally. The netrexxc ant task doesn't either one. It just accepts a string with the runtime platform path separator used correctly. Thus forcing us to build this string dynamically some way or another. IMHO using a gazillion '${path.separator}'s is just another workaround for the very same limitation :-) I just happen to find my solution a little more readable when classpath gets longer. Both are of course correct. --- Saludos / Kind regards. David Requena El 18/02/2010 23:50, Kermit Kiser escribió: > David ; > > I also use Ant for building my NetRexx projects. I am a little puzzled > by your example though - I have not had to use the "toString" trick at > all, although I did have to use the ${path.separator} property to > allow my classpaths to work on both Windows and Unix systems (which is > odd since using "/" for file.separator seems to work on both.): > > ------------------------------------------------------------------------------------------------------------- > > <target name="buildnrx" depends="compileJava" description="Compiles > NetRexx source files"> > <netrexxc srcDir="src" destDir="." includes="*.nrx" > > classpath=".${path.separator}${project.netrexx.libdir}/NetRexxC.jar${path.separator}${jedit.install.dir}/jedit.jar${path.separator}${jedit.plugins.dir}/ErrorList.jar" > > comments="false" savelog="false" time="true" compact="false" > verbose='verbose0' crossref="false" replace="false" > keep="false"/> > </target> > ------------------------------------------------------------------------------------------------------------- > > > Why do you need the toString trick? Is the "path.separator" property > not very well known? > > I wonder if the classpath wildcard is supported in Ant now? > > -- Kermit > > > > David Requena wrote: >> Alan, >> >>> You should take a look at the Apache Ant (at http://ant.apache.org/) >>> or Maven (at http://maven.apache.org/) projects as a means of >>> building your distribution package. I've used Ant both stand-alone >>> and inside Eclipse to generate target jar files then build >>> distribution packages that include all the referenced jar files, >>> shell scripts, property files, XML, images, web pages etc. with >>> everything in their correct places in a run-time directory hierarchy >>> then roll the whole bundle into tarballs and zip files. >>> >>> The nice thing about Ant is is it makes the build/package process >>> both repeatable and predictable. >>> >> >> Totally agree, that is in fact how NetRexxDE is built. >> >>> (I haven't tried but I suspect you could even coerce Ant to compile >>> NetRexx programs for you.) >>> >> >> There is an optional ant task for this purpose. Find below how I'm >> using it in NetRexxDE. I'm posting the whole target def it shows how >> I workaround an issue this netrexx-task has with path separator >> handling. >> >> <target name="compile" depends="-init"> >> <!-- NetRexx task should handle the classpath nested element >> on its own or, at least, properly convert the path >> separator >> in its classpath attribute to the platform's one. In the >> meantime we'll use the ${toString:path} trick >> --> >> <path id="netrexxc.classpath"> >> <pathelement location="${jedit.install.dir}/jedit.jar"/> >> <pathelement location="${project.src.dir}"/> >> <fileset dir="${jedit.jars.directory}"> >> <include name="NetRexxC.jar"/> >> <include name="ErrorList.jar"/> >> <include name="CommonControls.jar"/> >> <include name="SideKick.jar"/> >> <include name="ProjectViewer.jar"/> >> <include name="jh.jar"/> >> </fileset> >> </path> >> <netrexxc srcdir="${project.src.dir}" destdir="${project.build.dir}" >> crossref="false" >> replace="true" >> classpath="${toString:netrexxc.classpath}"> >> </netrexxc> >> </target> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Ibm-netrexx mailing list [hidden email] |
|
|
We had the the NetRexx ant task rewritten in NetRexx in a project many years ago. I'll dig it up and contact the author so it can be open sourced. This might enable us to adapt it easier to do the things that we want it to do - if needed.
best regards, René. On 19 feb 2010, at 11:56, David Requena wrote: > Kermit, > > You're building a classpath string 'by hand'. > > Customarily ant tasks taking a classpath do accept either: > > - a string with '/' as a path separator, then adapting this to the platform's actual path separator at runtime. > > - a '<path> construct with nested <patelement>, <fileset>, etc., then handling the platform stuff internally. > > The netrexxc ant task doesn't either one. It just accepts a string with the runtime platform path separator used correctly. Thus forcing us to build this string dynamically some way or another. > > IMHO using a gazillion '${path.separator}'s is just another workaround for the very same limitation :-) > > I just happen to find my solution a little more readable when classpath gets longer. > Both are of course correct. > > --- > Saludos / Kind regards. > David Requena > > > El 18/02/2010 23:50, Kermit Kiser escribió: >> David ; >> >> I also use Ant for building my NetRexx projects. I am a little puzzled by your example though - I have not had to use the "toString" trick at all, although I did have to use the ${path.separator} property to allow my classpaths to work on both Windows and Unix systems (which is odd since using "/" for file.separator seems to work on both.): >> >> ------------------------------------------------------------------------------------------------------------- >> <target name="buildnrx" depends="compileJava" description="Compiles NetRexx source files"> >> <netrexxc srcDir="src" destDir="." includes="*.nrx" >> classpath=".${path.separator}${project.netrexx.libdir}/NetRexxC.jar${path.separator}${jedit.install.dir}/jedit.jar${path.separator}${jedit.plugins.dir}/ErrorList.jar" >> comments="false" savelog="false" time="true" compact="false" >> verbose='verbose0' crossref="false" replace="false" keep="false"/> >> </target> >> ------------------------------------------------------------------------------------------------------------- >> >> Why do you need the toString trick? Is the "path.separator" property not very well known? >> >> I wonder if the classpath wildcard is supported in Ant now? >> >> -- Kermit >> >> >> >> David Requena wrote: >>> Alan, >>> >>>> You should take a look at the Apache Ant (at http://ant.apache.org/) or Maven (at http://maven.apache.org/) projects as a means of building your distribution package. I've used Ant both stand-alone and inside Eclipse to generate target jar files then build distribution packages that include all the referenced jar files, shell scripts, property files, XML, images, web pages etc. with everything in their correct places in a run-time directory hierarchy then roll the whole bundle into tarballs and zip files. >>>> >>>> The nice thing about Ant is is it makes the build/package process both repeatable and predictable. >>>> >>> >>> Totally agree, that is in fact how NetRexxDE is built. >>> >>>> (I haven't tried but I suspect you could even coerce Ant to compile NetRexx programs for you.) >>>> >>> >>> There is an optional ant task for this purpose. Find below how I'm using it in NetRexxDE. I'm posting the whole target def it shows how I workaround an issue this netrexx-task has with path separator handling. >>> >>> <target name="compile" depends="-init"> >>> <!-- NetRexx task should handle the classpath nested element >>> on its own or, at least, properly convert the path separator >>> in its classpath attribute to the platform's one. In the >>> meantime we'll use the ${toString:path} trick >>> --> >>> <path id="netrexxc.classpath"> >>> <pathelement location="${jedit.install.dir}/jedit.jar"/> >>> <pathelement location="${project.src.dir}"/> >>> <fileset dir="${jedit.jars.directory}"> >>> <include name="NetRexxC.jar"/> >>> <include name="ErrorList.jar"/> >>> <include name="CommonControls.jar"/> >>> <include name="SideKick.jar"/> >>> <include name="ProjectViewer.jar"/> >>> <include name="jh.jar"/> >>> </fileset> >>> </path> >>> <netrexxc srcdir="${project.src.dir}" destdir="${project.build.dir}" >>> crossref="false" >>> replace="true" >>> classpath="${toString:netrexxc.classpath}"> >>> </netrexxc> >>> </target> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Including *another* .jar file in MY .jar file
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 René Jansen schrieb am 19.02.2010 12:16: > We had the the NetRexx ant task rewritten in NetRexx in a project many years ago. I'll dig it up and contact the author so it can be open sourced. This might enable us to adapt it easier to do the things that we want it to do - if needed. > Hi René, I wrote a few patches to this NetRexxC task, too, but it was (and in my copy still is) still written in Java. AFAIR it was suppressing some messages and applying defaults to the options throughout an ant file I added. That was back in April 2002... Meanwhile I've patched it yet again, so that it can remove the .keep extension so that javadoc may run flawlessly right after, and the error messages tell the names of the real source files, because the NetRexx compiler messages refer to the already copied source files. Works great together with jEdit's error console to highlight errors right after building. - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkt+hjQACgkQfGgGu8y7ypASDwCgjQepV5SPN/qzbjuvFax5t2wr MB8AnjMGvjf8IKQ2cBYUD2mtdzSDKK33 =mERY -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi Patrick,
let's merge these into the NetRexx version at some point in time. I am not an avid ant user myself, but I see the merits and necessity when we are going to attempt IDE integration. best regards, René Jansen. On Fri, Feb 19, 2010 at 1:38 PM, Patric Bechtel <[hidden email]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > René Jansen schrieb am 19.02.2010 12:16: >> We had the the NetRexx ant task rewritten in NetRexx in a project many years ago. I'll dig it up and contact the author so it can be open sourced. This might enable us to adapt it easier to do the things that we want it to do - if needed. >> > Hi René, > > I wrote a few patches to this NetRexxC task, too, but it was (and in my > copy still is) still written in Java. AFAIR it was suppressing some > messages and applying defaults to the options throughout an ant file I > added. That was back in April 2002... > Meanwhile I've patched it yet again, so that it can remove the .keep > extension so that javadoc may run flawlessly right after, and the error > messages tell the names of the real source files, because the NetRexx > compiler messages refer to the already copied source files. Works great > together with jEdit's error console to highlight errors right after > building. > > - -- > Patric > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: GnuPT 2.5.2 > > iEYEARECAAYFAkt+hjQACgkQfGgGu8y7ypASDwCgjQepV5SPN/qzbjuvFax5t2wr > MB8AnjMGvjf8IKQ2cBYUD2mtdzSDKK33 > =mERY > -----END PGP SIGNATURE----- > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Including *another* .jar file in MY .jar file
|
|
In reply to this post by Patric Bechtel
El 19/02/2010 13:38, Patric Bechtel escribió: > Meanwhile I've patched it yet again, so that it can remove the .keep > extension so that javadoc may run flawlessly right after, and the error > messages tell the names of the real source files, because the NetRexx > compiler messages refer to the already copied source files. Works great > This is not happening to me... netrexxc errors point right to the real source files not the copied ones. I just added a couple regex to Console plugin options to have Errorlist point to the offending line/column in that file. This is an unmodified netrexxc ant task for sure. I just downloaded. it --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Introducing an *automatic* JavaDoc step after NetRexx Compilation
|
|
In reply to this post by rvjansen
Hi Patrick,
could you please mail (privately to [hidden email]) a copy of the patches you did to NetRexxC so that, please, I can do the JavaDoc step's of my own source (now all in NetRexx) by simply compiling the programs again ? That would be of real help for me! Tom. PS: Please note, that I also did change the Subject, just to be able to follow this thread more easily (hopefully for all of us) ... =========================================================================== René Jansen schrieb: > Hi Patrick, > > let's merge these into the NetRexx version at some point in time. I am > not an avid ant user myself, but I see the merits and necessity when > we are going to attempt IDE integration. > > best regards, > > René Jansen. > > On Fri, Feb 19, 2010 at 1:38 PM, Patric Bechtel <[hidden email]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> René Jansen schrieb am 19.02.2010 12:16: >> >>> We had the the NetRexx ant task rewritten in NetRexx in a project many years ago. I'll dig it up and contact the author so it can be open sourced. This might enable us to adapt it easier to do the things that we want it to do - if needed. >>> >>> >> Hi René, >> >> I wrote a few patches to this NetRexxC task, too, but it was (and in my >> copy still is) still written in Java. AFAIR it was suppressing some >> messages and applying defaults to the options throughout an ant file I >> added. That was back in April 2002... >> Meanwhile I've patched it yet again, so that it can remove the .keep >> extension so that javadoc may run flawlessly right after, and the error >> messages tell the names of the real source files, because the NetRexx >> compiler messages refer to the already copied source files. Works great >> together with jEdit's error console to highlight errors right after >> building. >> >> - -- >> Patric >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: GnuPT 2.5.2 >> >> iEYEARECAAYFAkt+hjQACgkQfGgGu8y7ypASDwCgjQepV5SPN/qzbjuvFax5t2wr >> MB8AnjMGvjf8IKQ2cBYUD2mtdzSDKK33 >> =mERY >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |