Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 16.11.01
    • Component/s: None
    • Labels:
      None

      Description

      With the implementation of the Gradle build methodology the name of the OFBiz executable changed from ofbiz.jar to ofbiz-gradle.jar.

      In order to keep consistency with older releases this should be changed so that the old name is back.

      1. OFBIZ-7893-build.gradle.patch
        0.3 kB
        Pierre Smits
      2. OFBIZ-7893-build.gradle-v2.patch
        4 kB
        Pierre Smits

        Issue Links

          Activity

          Hide
          pfm.smits Pierre Smits added a comment -

          This patch addresses the issue.

          Show
          pfm.smits Pierre Smits added a comment - This patch addresses the issue.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          AFAIK this has been done already not sure when and by who... It you confirm (use trunk HEAD) please close, thanks!

          Show
          jacques.le.roux Jacques Le Roux added a comment - AFAIK this has been done already not sure when and by who... It you confirm (use trunk HEAD) please close, thanks!
          Hide
          taher Taher Alkhateeb added a comment -

          This patch breaks the build script because it is dependent on the project name. The project name is simply the name of the root folder. So the jar takes the name of the folder that the project lives in. So if ofbiz is in /home/user/MyOfbiz then the jar would be created in /build/libs/MyOfbiz.jar

          If you want to make the name of the project permanent like "ofbiz" then you need to set it up accordingly in settings.gradle.

          I personally prefer if we keep it the way it is because it is nice to have your jar reflecting your directory name for clarity, but I don't mind fixing it if users prefer that.

          Show
          taher Taher Alkhateeb added a comment - This patch breaks the build script because it is dependent on the project name. The project name is simply the name of the root folder. So the jar takes the name of the folder that the project lives in. So if ofbiz is in /home/user/MyOfbiz then the jar would be created in /build/libs/MyOfbiz.jar If you want to make the name of the project permanent like "ofbiz" then you need to set it up accordingly in settings.gradle. I personally prefer if we keep it the way it is because it is nice to have your jar reflecting your directory name for clarity, but I don't mind fixing it if users prefer that.
          Hide
          pfm.smits Pierre Smits added a comment -

          It must be something that resides somewhere outside the project or is hidden in some folder/zip structure.

          Show
          pfm.smits Pierre Smits added a comment - It must be something that resides somewhere outside the project or is hidden in some folder/zip structure.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          We should discuss this on dev ML

          Show
          jacques.le.roux Jacques Le Roux added a comment - We should discuss this on dev ML
          Hide
          taher Taher Alkhateeb added a comment -

          Hi Jacques,

          Sure, please go ahead and start a thread.

          Show
          taher Taher Alkhateeb added a comment - Hi Jacques, Sure, please go ahead and start a thread.
          Hide
          pfm.smits Pierre Smits added a comment - - edited

          Thanks for your opinion on the nice to have. But deviations on built time (based on what each developer likes with respect to his development environment):

          • creates unnecessary inconsistencies from old to new releases
          • complicates writing descriptive howto and other OFBiz documents unnecessarily.
          Show
          pfm.smits Pierre Smits added a comment - - edited Thanks for your opinion on the nice to have. But deviations on built time (based on what each developer likes with respect to his development environment): creates unnecessary inconsistencies from old to new releases complicates writing descriptive howto and other OFBiz documents unnecessarily.
          Hide
          taher Taher Alkhateeb added a comment -

          There are no inconsistencies because everything is automated and works. Furthermore, we should not write any howto and other OFBiz documents explaining how to override the build system and do things by hand. It violates the original purpose of the build system which is to provide ease and comfort for the users.

          Show
          taher Taher Alkhateeb added a comment - There are no inconsistencies because everything is automated and works. Furthermore, we should not write any howto and other OFBiz documents explaining how to override the build system and do things by hand. It violates the original purpose of the build system which is to provide ease and comfort for the users.
          Hide
          pfm.smits Pierre Smits added a comment -

          Thank you for sharing your viewpoint on what the OFBiz community should and/or should not do. Feel free to discuss that in the dev ml.

          Show
          pfm.smits Pierre Smits added a comment - Thank you for sharing your viewpoint on what the OFBiz community should and/or should not do. Feel free to discuss that in the dev ml.
          Hide
          pfm.smits Pierre Smits added a comment -

          This new patch addresses the issue. It keeps in line with conventions used in older releases.

          It also addresses OFBIZ-7783, with respect of not getting external libs in the project folder

          It also addresses OFBIZ-7796, with respect of not being able to run OFBiz as a service when using Debian/Ubuntu
          Within this, it also addresses

          • the JAVA_BINARY setting as that was still reflecting Java version 1.4.2
          • the OFBIZ_HOME setting as it is customary to not have this set to the home directory of a user
          Show
          pfm.smits Pierre Smits added a comment - This new patch addresses the issue. It keeps in line with conventions used in older releases. It also addresses OFBIZ-7783 , with respect of not getting external libs in the project folder It also addresses OFBIZ-7796 , with respect of not being able to run OFBiz as a service when using Debian/Ubuntu Within this, it also addresses the JAVA_BINARY setting as that was still reflecting Java version 1.4.2 the OFBIZ_HOME setting as it is customary to not have this set to the home directory of a user
          Hide
          taher Taher Alkhateeb added a comment -

          -1 from my side on latest patch.

          Seems to be a patch too specific for your hosting requirements. I think Gradle should be an integral part of the OFBiz solution including deployment.

          Show
          taher Taher Alkhateeb added a comment - -1 from my side on latest patch. Seems to be a patch too specific for your hosting requirements. I think Gradle should be an integral part of the OFBiz solution including deployment.
          Hide
          pfm.smits Pierre Smits added a comment - - edited

          Hi Taher Alkhateeb,

          No, it is not just applicable for my hosting environments. I is intended to keep future releases in line with what our current adopters already have and know.

          And that not only relates to deployment, but it also applies to development. When a developer has multiple checkouts, he should - under the standard convention (of Gradle, as implemented by you) switch for each checkout to a different executor. This patch alleviates that.

          It creates consistency in multiple ways, that eases work down the line.

          Show
          pfm.smits Pierre Smits added a comment - - edited Hi Taher Alkhateeb , No, it is not just applicable for my hosting environments. I is intended to keep future releases in line with what our current adopters already have and know. And that not only relates to deployment, but it also applies to development. When a developer has multiple checkouts, he should - under the standard convention (of Gradle, as implemented by you) switch for each checkout to a different executor. This patch alleviates that. It creates consistency in multiple ways, that eases work down the line.
          Hide
          taher Taher Alkhateeb added a comment -

          Oh it also breaks the build script

          Show
          taher Taher Alkhateeb added a comment - Oh it also breaks the build script
          Hide
          pfm.smits Pierre Smits added a comment -

          Hi Taher Alkhateeb,

          That is unfortunate to read. Could you provide a log excerpt so that I can assess the situation?

          Show
          pfm.smits Pierre Smits added a comment - Hi Taher Alkhateeb , That is unfortunate to read. Could you provide a log excerpt so that I can assess the situation?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Pierre your second patch is deprecated (better to keep the same name, Jira then grays the older ones, easier to pick the last one, this in contributor best practices)

          1. I have already updated rc.ofbiz and rc.ofbiz.for.debian
          2. OFBIZ-7930 proposes a more advanced copyExternalJars task than copyToLib (with now locally its counterpart cleanExternalJars which I have problems with - I'll explain later)
          3. What developmentGroup is intended for?

          So I could agree about (but moot point)

           +def jvmArguments = ['-Xms528M', '-Xmx1024M']
          

          and maybe

          +    archiveName = "ofbiz.jar"
          +    destinationDir = file("$rootDir")
          +    exclude ('*.xml')
          +    exclude ('*.txt')
          +    exclude ('*.jks')
          +    exclude ('README'
          

          but I think it's incomplete

          Thanks for your work!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Pierre your second patch is deprecated (better to keep the same name, Jira then grays the older ones, easier to pick the last one, this in contributor best practices) I have already updated rc.ofbiz and rc.ofbiz.for.debian OFBIZ-7930 proposes a more advanced copyExternalJars task than copyToLib (with now locally its counterpart cleanExternalJars which I have problems with - I'll explain later) What developmentGroup is intended for? So I could agree about (but moot point) +def jvmArguments = ['-Xms528M', '-Xmx1024M'] and maybe + archiveName = "ofbiz.jar" + destinationDir = file( "$rootDir" ) + exclude ('*.xml') + exclude ('*.txt') + exclude ('*.jks') + exclude ('README' but I think it's incomplete Thanks for your work!
          Hide
          taher Taher Alkhateeb added a comment -

          Hi Jacques,

          I also like the idea of improving the jvm memory, however I recommend not to change the generated jar and apply the changes above because:

          • by convention all gradle generated artifacts go in /build. there is even a buildDir variable. the jar by convention always sits next to the classes (even back in ant days except the start component)
          • the ofbiz.jar you are looking at is not the same ofbiz.jar. It contains the full classpath of all the libraries which are hardcoded including things in your gradle cache. This requires re-running the build for any tiny changes. So using Java directly is really unreliable. That is why, for example, any server tasks depends on "build" in gradle to always make sure the classpath is correct so that the user does not have to call build after every change.
          • Gradle as a full programming language is part of the OFBiz solution. One of the primary and excellent improvements it brought along is to isolate the user from knowing and passing JVM arguments. Even interacting with the server has a much nicer syntax and everything like sending to background or activating debug mode is all done for you wihout worrying about any details. So my recommendation is to let users focus on the work and let gradle handle the java details.
          • Changing the jar name is not the best way, rather we should rename the project in settings.gradle. This is safer and maintains multiple conventions in place.
          • The exclusions above are not the best solution and adds code bloat because we put them there. Instead we should fine tune the sourcesets block (specifically the resources section) to exclude whatever we want in there.
          • This patch was made specifically for a user who has specific deployment requirements in which the build system is stripped away, for example even the rc scripts are reconverted from gradle to java. This is not a preferred idea for the above mentioned reasons.

          So if you want to change things, I would recommend the following:

          • we can apply the jvm memory arguments
          • we can change and fix the name of the project to "ofbiz" in settings.gradle which would avoid the interventions on the jar task that affects other operations.
          Show
          taher Taher Alkhateeb added a comment - Hi Jacques, I also like the idea of improving the jvm memory, however I recommend not to change the generated jar and apply the changes above because: by convention all gradle generated artifacts go in /build. there is even a buildDir variable. the jar by convention always sits next to the classes (even back in ant days except the start component) the ofbiz.jar you are looking at is not the same ofbiz.jar. It contains the full classpath of all the libraries which are hardcoded including things in your gradle cache. This requires re-running the build for any tiny changes. So using Java directly is really unreliable. That is why, for example, any server tasks depends on "build" in gradle to always make sure the classpath is correct so that the user does not have to call build after every change. Gradle as a full programming language is part of the OFBiz solution. One of the primary and excellent improvements it brought along is to isolate the user from knowing and passing JVM arguments. Even interacting with the server has a much nicer syntax and everything like sending to background or activating debug mode is all done for you wihout worrying about any details. So my recommendation is to let users focus on the work and let gradle handle the java details. Changing the jar name is not the best way, rather we should rename the project in settings.gradle. This is safer and maintains multiple conventions in place. The exclusions above are not the best solution and adds code bloat because we put them there. Instead we should fine tune the sourcesets block (specifically the resources section) to exclude whatever we want in there. This patch was made specifically for a user who has specific deployment requirements in which the build system is stripped away, for example even the rc scripts are reconverted from gradle to java. This is not a preferred idea for the above mentioned reasons. So if you want to change things, I would recommend the following: we can apply the jvm memory arguments we can change and fix the name of the project to "ofbiz" in settings.gradle which would avoid the interventions on the jar task that affects other operations.
          Hide
          taher Taher Alkhateeb added a comment -

          I also forgot to mention there is a big inefficiency and waste of space from copying everything from the gradle cache to /libs. Not to mention that this goes againt convention not only in Gradle, but also maven and even django, ruby on rails, and node.js. Modern systems usually externalize dependencies away from the source code.

          Show
          taher Taher Alkhateeb added a comment - I also forgot to mention there is a big inefficiency and waste of space from copying everything from the gradle cache to /libs. Not to mention that this goes againt convention not only in Gradle, but also maven and even django, ruby on rails, and node.js. Modern systems usually externalize dependencies away from the source code.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I agree and could feel the pain (more about that later). The reason I need that on my local machine (same for any person interested by external jars and security) is explained at OFBIZ-7930

          Show
          jacques.le.roux Jacques Le Roux added a comment - I agree and could feel the pain (more about that later). The reason I need that on my local machine (same for any person interested by external jars and security) is explained at OFBIZ-7930
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Your explanations and suggestions in the longer comment above are good ideas, thanks!

          BTW I like the Jira "Reply" feature, it works like responding to a thread, sometimes it's better to create a new one, really not always obvious when I must say

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Your explanations and suggestions in the longer comment above are good ideas, thanks! BTW I like the Jira "Reply" feature, it works like responding to a thread, sometimes it's better to create a new one, really not always obvious when I must say
          Hide
          taher Taher Alkhateeb added a comment -

          ok replying in there

          Show
          taher Taher Alkhateeb added a comment - ok replying in there
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Taher, you said

          The exclusions above are not the best solution and adds code bloat because we put them there. Instead we should fine tune the sourcesets block (specifically the resources section) to exclude whatever we want in there.

          But did not put in your suggestions summary, is there a reason?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Taher, you said The exclusions above are not the best solution and adds code bloat because we put them there. Instead we should fine tune the sourcesets block (specifically the resources section) to exclude whatever we want in there. But did not put in your suggestions summary, is there a reason?
          Hide
          taher Taher Alkhateeb added a comment -

          I don't think it is necessary to conclude only on summary Obviously I agree as per my above quoted text. I was focusing on the points that seem more important to me like generated artifacts and memory settings.

          Speaking of that point, it would be great to identify the exact resources needed for startup. The reason why we have excess ones is because I included everything in every config folder. I know that the properties files in the start component are necessary and probably also the files in the config directory of the base component. I'm not sure that this covers everything needed for starting up the server. Ideas?

          Show
          taher Taher Alkhateeb added a comment - I don't think it is necessary to conclude only on summary Obviously I agree as per my above quoted text. I was focusing on the points that seem more important to me like generated artifacts and memory settings. Speaking of that point, it would be great to identify the exact resources needed for startup. The reason why we have excess ones is because I included everything in every config folder. I know that the properties files in the start component are necessary and probably also the files in the config directory of the base component. I'm not sure that this covers everything needed for starting up the server. Ideas?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I think we need more research than ideas here. I'll do you summary suggestions, close this issue as done and create a new Jira for the quoted point above, thanks!

          Show
          jacques.le.roux Jacques Le Roux added a comment - I think we need more research than ideas here. I'll do you summary suggestions, close this issue as done and create a new Jira for the quoted point above, thanks!
          Hide
          taher Taher Alkhateeb added a comment -

          ok, noted and agreed. If you can point me to the newly created JIRAs it would be great so I can help however I can.

          Show
          taher Taher Alkhateeb added a comment - ok, noted and agreed. If you can point me to the newly created JIRAs it would be great so I can help however I can.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          The max memory was set at 1024M at r1754518
          The project name is now ofbiz, done at r1754623
          Closing following above exchanges

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited The max memory was set at 1024M at r1754518 The project name is now ofbiz, done at r1754623 Closing following above exchanges
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I created OFBIZ-7937 "Fine tune the sourcesets block" following Taher's suggestion above. We need to clarify what we need to do there...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I created OFBIZ-7937 "Fine tune the sourcesets block" following Taher's suggestion above. We need to clarify what we need to do there...

            People

            • Assignee:
              jacques.le.roux Jacques Le Roux
              Reporter:
              pfm.smits Pierre Smits
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development