Fwd: Re: Initial impressions of Android Studio

[Kermit Kiser]

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

On 9/26/2014 6:54 AM, George Hovey wrote:

Hi Kermit,

Re your post of 11 Sept.

I guess I don't understand why it is necessary "to develop a netrexx build process".

Perhaps I have some huge blind spot, but it seems to me that Android need know nothing about NetRexx (other than NetRexxR.jar).  The necessary Android code is just written in NetRexx and compiled to Java outside of Android Studio.  The .java files are placed where Android expects them.   Android doesn't know or care how they were produced.

Is this different, in its effect on the Android build, from coding directly in Java?

On Thu, Sep 11, 2014 at 1:19 PM, Kermit <[hidden email]> wrote:

Since google is forcing developers to give up Eclipse and Ant, I think that we have no choice but to learn gradle and it's "groovy" control language to develop a netrexx build process that will work with the latest android. Android builds are a multi step process that first builds any "library" projects required by the main project, then compiles all resource components (mostly graphical elements defined with xml) into a format that java code can reference, compiles the java modules, then translates classes into a "dex" format that an android vm can run and bundles it all into the downloadable/installable "apk" module. That is over simplified since production apks have to be digitally signed by an approved developer key. Much work is still ahead!
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 9:23:28 AM PDT, George Hovey <[hidden email]> wrote:

Kermit,

Haven't a clue.  I assume it requires knowledge beyond "Hello World".  What do you think?

On Thu, Sep 11, 2014 at 12:14 PM, Kermit <[hidden email]> wrote:

How do you compile the xml graphical components so that the NetRexx code can reference them?
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 7:01:36 AM PDT, George Hovey <[hidden email]> wrote:

Bliss.  Three days of reading Android docs and searching for the answer to a problem produced

   Hello World (from NetRexx)

using Google's Android Studio ("AS", beta 0.8.9).  For the benefit of those wanting to come to grips with Android Studio but fearing the worst (e.g. me), I'll briefly describe my experience.

Android Studio is a custom version of IntelliJ IDEA's Android plugin.  Why not use the original?  I don't know, but I can see Google's version seems to be removing any trace of extraneous elements in order to improve the user experience.  There is a cost.  Like all of Google's Android development efforts this proceeds at a blistering pace and the documentation is always behind.  So you are often forced to read IntelliJ's docs which requires some reading between the lines.

This happened when I attempted to tell AS about NetRexxR.jar.  The d! ocs unhelpfully discus! sed "remote and local binary dependencies" which sounded like jars but seemed to have no precise definitions.   I could see a couple of plausible places to put it, but my naive attempts produced results from the build like "unable to assemble NetRexxR.jar" (huh?).  This turned out to be a popular question at StackOverflow, and produced several complicated and wrong answers (as did AS), and one right one which I'll recite in case the docs haven't caught up by the time you try this:

       -- Copy jar to libs directory in the app
       -- Refresh project so libs show up in the structure
       -- Expand libs and right click on the jar
       -- Select "Add as Library"

As an example of the endless felicitous touches in AS, you can right click on any item in the build tree and produce an Explorer window (under Windows) of its containing directory.  This makes! moving NetRexx's ! .java files to their proper place in AS simple.

In case you have no preconceived notions about work flow I'll describe mine, which is low-tech but starkly simple.  I work under Windows and use the VIRTUAWIN multiple desktop program to reduce clutter; a single keystroke moves to any of 9 desktops.   I use three adjacent desktops for Android development.  One contains docs, another Android Studio, and the last jEdit and a command window.  For the moment I am keeping my .nrx sources outside of AS.  A build cycle is:

   1) Edit in jEdit.
   2) Compile in the command window
      -- use the ugly form of .java output so line numbers remain in sync
      -- output NetRexxC messages to a file which is constantly visible in
         jEdit.
   3) Move the .java to AS with a script
   4) Build.
  
Note that AS and jEdit are not coupled in any way, which I regard as a plus.
!
My initial impression of Android Studio is very favorable: fit and finish are outstanding and it appears to be the result of some very innovative thinking about the build process.

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/

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

On 9/26/2014 6:54 AM, George Hovey wrote:

Hi Kermit,

Re your post of 11 Sept.

I guess I don't understand why it is necessary "to develop a netrexx build process".

Perhaps I have some huge blind spot, but it seems to me that Android need know nothing about NetRexx (other than NetRexxR.jar).  The necessary Android code is just written in NetRexx and compiled to Java outside of Android Studio.  The .java files are placed where Android expects them.   Android doesn't know or care how they were produced.

Is this different, in its effect on the Android build, from coding directly in Java?

On Thu, Sep 11, 2014 at 1:19 PM, Kermit <[hidden email]> wrote:

Since google is forcing developers to give up Eclipse and Ant, I think that we have no choice but to learn gradle and it's "groovy" control language to develop a netrexx build process that will work with the latest android. Android builds are a multi step process that first builds any "library" projects required by the main project, then compiles all resource components (mostly graphical elements defined with xml) into a format that java code can reference, compiles the java modules, then translates classes into a "dex" format that an android vm can run and bundles it all into the downloadable/installable "apk" module. That is over simplified since production apks have to be digitally signed by an approved developer key. Much work is still ahead!
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 9:23:28 AM PDT, George Hovey <[hidden email]> wrote:

Kermit,

Haven't a clue.  I assume it requires knowledge beyond "Hello World".  What do you think?

On Thu, Sep 11, 2014 at 12:14 PM, Kermit <[hidden email]> wrote:

How do you compile the xml graphical components so that the NetRexx code can reference them?
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 7:01:36 AM PDT, George Hovey <[hidden email]> wrote:

Bliss.  Three days of reading Android docs and searching for the answer to a problem produced

   Hello World (from NetRexx)

using Google's Android Studio ("AS", beta 0.8.9).  For the benefit of those wanting to come to grips with Android Studio but fearing the worst (e.g. me), I'll briefly describe my experience.

Android Studio is a custom version of IntelliJ IDEA's Android plugin.  Why not use the original?  I don't know, but I can see Google's version seems to be removing any trace of extraneous elements in order to improve the user experience.  There is a cost.  Like all of Google's Android development efforts this proceeds at a blistering pace and the documentation is always behind.  So you are often forced to read IntelliJ's docs which requires some reading between the lines.

This happened when I attempted to tell AS about NetRexxR.jar.  The d! ocs unhelpfully discus! sed "remote and local binary dependencies" which sounded like jars but seemed to have no precise definitions.   I could see a couple of plausible places to put it, but my naive attempts produced results from the build like "unable to assemble NetRexxR.jar" (huh?).  This turned out to be a popular question at StackOverflow, and produced several complicated and wrong answers (as did AS), and one right one which I'll recite in case the docs haven't caught up by the time you try this:

       -- Copy jar to libs directory in the app
       -- Refresh project so libs show up in the structure
       -- Expand libs and right click on the jar
       -- Select "Add as Library"

As an example of the endless felicitous touches in AS, you can right click on any item in the build tree and produce an Explorer window (under Windows) of its containing directory.  This makes! moving NetRexx's ! .java files to their proper place in AS simple.

In case you have no preconceived notions about work flow I'll describe mine, which is low-tech but starkly simple.  I work under Windows and use the VIRTUAWIN multiple desktop program to reduce clutter; a single keystroke moves to any of 9 desktops.   I use three adjacent desktops for Android development.  One contains docs, another Android Studio, and the last jEdit and a command window.  For the moment I am keeping my .nrx sources outside of AS.  A build cycle is:

   1) Edit in jEdit.
   2) Compile in the command window
      -- use the ugly form of .java output so line numbers remain in sync
      -- output NetRexxC messages to a file which is constantly visible in
         jEdit.
   3) Move the .java to AS with a script
   4) Build.
  
Note that AS and jEdit are not coupled in any way, which I regard as a plus.
!
My initial impression of Android Studio is very favorable: fit and finish are outstanding and it appears to be the result of some very innovative thinking about the build process.

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/

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

[rvjansen]

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

On 9/26/2014 6:54 AM, George Hovey wrote:

Hi Kermit,

Re your post of 11 Sept.

I guess I don't understand why it is necessary "to develop a netrexx build process".

Perhaps I have some huge blind spot, but it seems to me that Android need know nothing about NetRexx (other than NetRexxR.jar).  The necessary Android code is just written in NetRexx and compiled to Java outside of Android Studio.  The .java files are placed where Android expects them.   Android doesn't know or care how they were produced.

Is this different, in its effect on the Android build, from coding directly in Java?

On Thu, Sep 11, 2014 at 1:19 PM, Kermit <[hidden email]> wrote:

Since google is forcing developers to give up Eclipse and Ant, I think that we have no choice but to learn gradle and it's "groovy" control language to develop a netrexx build process that will work with the latest android. Android builds are a multi step process that first builds any "library" projects required by the main project, then compiles all resource components (mostly graphical elements defined with xml) into a format that java code can reference, compiles the java modules, then translates classes into a "dex" format that an android vm can run and bundles it all into the downloadable/installable "apk" module. That is over simplified since production apks have to be digitally signed by an approved developer key. Much work is still ahead!
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 9:23:28 AM PDT, George Hovey <[hidden email]> wrote:

Kermit,

Haven't a clue.  I assume it requires knowledge beyond "Hello World".  What do you think?

On Thu, Sep 11, 2014 at 12:14 PM, Kermit <[hidden email]> wrote:

How do you compile the xml graphical components so that the NetRexx code can reference them?
--
Sent from my Android device with K-9 Mail.

On September 11, 2014 7:01:36 AM PDT, George Hovey <[hidden email]> wrote:

Bliss.  Three days of reading Android docs and searching for the answer to a problem produced

   Hello World (from NetRexx)

using Google's Android Studio ("AS", beta 0.8.9).  For the benefit of those wanting to come to grips with Android Studio but fearing the worst (e.g. me), I'll briefly describe my experience.

Android Studio is a custom version of IntelliJ IDEA's Android plugin.  Why not use the original?  I don't know, but I can see Google's version seems to be removing any trace of extraneous elements in order to improve the user experience.  There is a cost.  Like all of Google's Android development efforts this proceeds at a blistering pace and the documentation is always behind.  So you are often forced to read IntelliJ's docs which requires some reading between the lines.

This happened when I attempted to tell AS about NetRexxR.jar.  The d! ocs unhelpfully discus! sed "remote and local binary dependencies" which sounded like jars but seemed to have no precise definitions.   I could see a couple of plausible places to put it, but my naive attempts produced results from the build like "unable to assemble NetRexxR.jar" (huh?).  This turned out to be a popular question at StackOverflow, and produced several complicated and wrong answers (as did AS), and one right one which I'll recite in case the docs haven't caught up by the time you try this:

       -- Copy jar to libs directory in the app
       -- Refresh project so libs show up in the structure
       -- Expand libs and right click on the jar
       -- Select "Add as Library"

As an example of the endless felicitous touches in AS, you can right click on any item in the build tree and produce an Explorer window (under Windows) of its containing directory.  This makes! moving NetRexx's ! .java files to their proper place in AS simple.

In case you have no preconceived notions about work flow I'll describe mine, which is low-tech but starkly simple.  I work under Windows and use the VIRTUAWIN multiple desktop program to reduce clutter; a single keystroke moves to any of 9 desktops.   I use three adjacent desktops for Android development.  One contains docs, another Android Studio, and the last jEdit and a command window.  For the moment I am keeping my .nrx sources outside of AS.  A build cycle is:

   1) Edit in jEdit.
   2) Compile in the command window
      -- use the ugly form of .java output so line numbers remain in sync
      -- output NetRexxC messages to a file which is constantly visible in
         jEdit.
   3) Move the .java to AS with a script
   4) Build.
  
Note that AS and jEdit are not coupled in any way, which I regard as a plus.
!
My initial impression of Android Studio is very favorable: fit and finish are outstanding and it appears to be the result of some very innovative thinking about the build process.

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/

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

[Kermit Kiser]

It seems that neither my experience, opinion nor logical explanations have any effect on this discussion so I guess everyone will have to discover for themselves that many if not most Android facilities are not available to NetRexx code that is compiled outside of the Android build process.

I will only suggest here that Google's tool developers felt that the Android build process was so complex that they could no longer support it using Ant alone and so they have switched it to Gradle which is a kind of cross between the Ant and Maven build systems.

Meanwhile I will continue to look into integrating NetRexx with the Gradle and Android build systems.

You can use the code I posted anyway you wish but I consider it a bit premature for documentation or general release.

-- Kermit

PS: Here is a interesting diagram of the evolution of build tools related to Java:

http://kermitkiser.com/NetRexx/Build%20Tool%20Evolutions.html

On 9/29/2014 12:17 PM, René Jansen wrote:

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

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

[rvjansen]

Kermit,

with my apologies if I have conveyed the impression not to have taken you mail seriously, I must admit that I did not try any of this myself yet. Let's hold off on the release of the code yet until everyone is comfortable in doing that.

best regards,

René.

On 1 okt. 2014, at 00:39, Kermit Kiser <[hidden email]> wrote:

It seems that neither my experience, opinion nor logical explanations have any effect on this discussion so I guess everyone will have to discover for themselves that many if not most Android facilities are not available to NetRexx code that is compiled outside of the Android build process.

I will only suggest here that Google's tool developers felt that the Android build process was so complex that they could no longer support it using Ant alone and so they have switched it to Gradle which is a kind of cross between the Ant and Maven build systems.

Meanwhile I will continue to look into integrating NetRexx with the Gradle and Android build systems.

You can use the code I posted anyway you wish but I consider it a bit premature for documentation or general release.

-- Kermit

PS: Here is a interesting diagram of the evolution of build tools related to Java:

http://kermitkiser.com/NetRexx/Build%20Tool%20Evolutions.html

On 9/29/2014 12:17 PM, René Jansen wrote:

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

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

Kermit, *thanks again* to documenting so thoroughly Your findings :-)
Thomas.
=============================================================

Am 01.10.2014 um 00:39 schrieb Kermit Kiser:

It seems that neither my experience, opinion nor logical explanations have any effect on this discussion so I guess everyone will have to discover for themselves that many if not most Android facilities are not available to NetRexx code that is compiled outside of the Android build process.

I will only suggest here that Google's tool developers felt that the Android build process was so complex that they could no longer support it using Ant alone and so they have switched it to Gradle which is a kind of cross between the Ant and Maven build systems.

Meanwhile I will continue to look into integrating NetRexx with the Gradle and Android build systems.

You can use the code I posted anyway you wish but I consider it a bit premature for documentation or general release.

-- Kermit

PS: Here is a interesting diagram of the evolution of build tools related to Java:

http://kermitkiser.com/NetRexx/Build%20Tool%20Evolutions.html

On 9/29/2014 12:17 PM, René Jansen wrote:

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

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

Here is an interesting take on Android Studio v. Eclipse for Android development.  Obviously the author has strong opinions.

https://www.infinum.co/the-capsized-eight/articles/eclipse-is-dead-for-android-development-and-i-helped-kill-it

On Wed, Oct 1, 2014 at 7:20 PM, Thomas Schneider <[hidden email]> wrote:

Kermit, *thanks again* to documenting so thoroughly Your findings :-)
Thomas.
=============================================================

Am 01.10.2014 um 00:39 schrieb Kermit Kiser:

It seems that neither my experience, opinion nor logical explanations have any effect on this discussion so I guess everyone will have to discover for themselves that many if not most Android facilities are not available to NetRexx code that is compiled outside of the Android build process.

I will only suggest here that Google's tool developers felt that the Android build process was so complex that they could no longer support it using Ant alone and so they have switched it to Gradle which is a kind of cross between the Ant and Maven build systems.

Meanwhile I will continue to look into integrating NetRexx with the Gradle and Android build systems.

You can use the code I posted anyway you wish but I consider it a bit premature for documentation or general release.

-- Kermit

PS: Here is a interesting diagram of the evolution of build tools related to Java:

http://kermitkiser.com/NetRexx/Build%20Tool%20Evolutions.html

On 9/29/2014 12:17 PM, René Jansen wrote:

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

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

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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

[George Hovey-2]

Here is a tutorial on Gradle/Android Studio that appears to know what it is talking about.

http://rominirani.com/2014/07/28/gradle-tutorial-series-an-overview/

On Fri, Oct 3, 2014 at 12:31 PM, George Hovey <[hidden email]> wrote:

Here is an interesting take on Android Studio v. Eclipse for Android development.  Obviously the author has strong opinions.

https://www.infinum.co/the-capsized-eight/articles/eclipse-is-dead-for-android-development-and-i-helped-kill-it

On Wed, Oct 1, 2014 at 7:20 PM, Thomas Schneider <[hidden email]> wrote:

Kermit, *thanks again* to documenting so thoroughly Your findings :-)
Thomas.
=============================================================

Am 01.10.2014 um 00:39 schrieb Kermit Kiser:

It seems that neither my experience, opinion nor logical explanations have any effect on this discussion so I guess everyone will have to discover for themselves that many if not most Android facilities are not available to NetRexx code that is compiled outside of the Android build process.

I will only suggest here that Google's tool developers felt that the Android build process was so complex that they could no longer support it using Ant alone and so they have switched it to Gradle which is a kind of cross between the Ant and Maven build systems.

Meanwhile I will continue to look into integrating NetRexx with the Gradle and Android build systems.

You can use the code I posted anyway you wish but I consider it a bit premature for documentation or general release.

-- Kermit

PS: Here is a interesting diagram of the evolution of build tools related to Java:

http://kermitkiser.com/NetRexx/Build%20Tool%20Evolutions.html

On 9/29/2014 12:17 PM, René Jansen wrote:

I certainly would like to see us able to build NetRexx in most building tools, but I must say that George is entirely correct in stating that the world does not come to an end if some tools does not grok NetRexx rightaway. My NetBeans NetRexx userinterface code does that exactly the same way: some decade ago NetBeans mistakenly ditched 'make' builds for 'ant' builds and imposed a bondage-and-discipline directory structure. Since those days I am still a happy NetBeans user (for the 1,5 graphical userinterface that I make per year) but I run my NetRexx builds from the outside, and let NetBeans pick up the changed java in its builds. Although I still think that 'target' directories are only useful if you build for different target architectures (which we don't in NetRexx  - if we really stretched the concept we could compile for different bytecode levels).

I am happy though with the gradle code. Let me know if it is something for the Programmer's Guide or something that we can ship in 3.04. I am afraid I have to look into Maven next -  it is company standard at my customer site for builds so I cannot really escape.

best regards,

René.

On 29 sep. 2014, at 15:53, George Hovey <[hidden email]> wrote:

Kermit,

I certainly take your point that "Hello World" is not an adequate vehicle for drawing sweeping conclusions about the NetRexx build process.  However, the approach I have proposed, namely compiling NetRexx and using the resultant .java files to populate the Android Studio source tree [remember: NetRexxC produces .java, not .class files] prior to running the out-of-box build would be a significant step forward if it works.

At present we are faced with an intolerable situation.  I think most would agree that NetRexx must have a presence in the Android world.  One prerequisite is a rock-solid build process.  And Google has just demonstrated that they can invalidate our current build at will.  But this is a volunteer outfit and we cannot guarantee that the necessary people will be available when such a fire needs to be put out.  The build problem would be solved if we could just use Android Studio's stock version.

A test of the proposed approach, using source capable of exercising all the issues you have described, is of the great importance.  If you or someone else with a working app could try this we might put the matter to rest.  I am in the design phase of an app that should be suitable, but it is some way off.  I will certainly report my experience.

As to the approach itself, your post [Fri, 26 Sep 2014 19:42:01 -0700] has a telling comment: "The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot."  Doesn't this argue for moving the compile (to .java) outside of the build?

On Sat, Sep 27, 2014 at 5:31 PM, Kermit Kiser <[hidden email]> wrote:

My reply did not get posted to the list as it was over the size limit with the diagrams inline so I am resending it without the inline images.

I also have some good news: After a few hours of research and head banging, I have managed to get Gradle to compile a NetRexx program!

Although Gradle is distributed with an integrated version of Ant, only the core Ant tasks are defined by default so it is necessary to use a taskdef to connect to optional Ant tasks like a NetRexx compile. (A Gradle "task" is equivalent to an Ant "target".) Here is the "build.gradle" code that allowed me to run the NetRexx project's Ant task for NetRexx compiles:

task nrc << {
    ant {
        taskdef(name: 'netrexxc',
                classname: 'org.apache.tools.ant.taskdefs.optional.NetRexx',
                classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
        netrexxc(srcDir:'.', destDir:'.', includes:'MyProgram.nrx', classpath: 'c:/NetRexx/NetRexx303/GA/tools/ant-task/ant-netrexx.jar;c:/NetRexx/NetRexx303/GA/lib/NetRexxC.jar')
    }
}

Note that the classpath to NetRexx and the Ant task must be specified in both the taskdef and the method call in order to work. I am hopeful that this bootstrap technique will allow us to develop a native Gradle plugin and make NetRexx a fully supported language there.

-- Kermit

-------- Original Message --------

Subject:	Re: [Ibm-netrexx] Initial impressions of Android Studio
Date:	Fri, 26 Sep 2014 19:42:01 -0700
From:	Kermit Kiser [hidden email]
To:	IBM Netrexx [hidden email]

George --

You are correct that Android does not need to know anything about NetRexx. Unfortunately that is not true of the build process for Android applications which is complex even in simple cases.

Any non-trivial Android application is a graphic user interface with probable multiple screen layouts (which are defined in XML files), image files (Icons at least), sound files, widget definitions, manifest (more XML), and other resources such as i18n language translation files. These things have to be converted to an Android internal format along with dynamically building an "R.java" source module which is compiled into a Java class file of object references to the resources. This has to be done before anything can be found by the NetRexx compiler. If you examine the visual images in the articles linked below which give a couple of different interpretations of an Android build, you will see that the NetRexx compile step has to be carefully woven into the correct place in the middle of the process somehow.

http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process

http://stackoverflow.com/questions/18951048/android-build-process-how-it-works


The above build process images are over-simplified (and somewhat imprecise) because in the case of using "library projects", extra steps are needed to make the library assets referable from NetRexx code.

The difference from coding in Java is that Java app code can be compiled directly with the generated R.java source code while NetRexx cannot. NetRexx source must compile after Java code compiles but before the "dx" translation to Dalvik classes.

Does that clarify things at all?

-- Kermit

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

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

--

"I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen

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