[jira] [Comment Edited] (OFBIZ-7783) External library files are not in the OFBiz folder structure.
[ https://issues.apache.org/jira/browse/OFBIZ-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15432332#comment-15432332 ] Jacques Le Roux edited comment on OFBIZ-7783 at 8/30/16 9:16 PM: - Thanks Taher, Before we discuss this more on the dev ML, just some points: # archiving the Gradle cache is not enough, because you can have not only OFBiz related libs in it, for instance on a dev machine * which use Eclipse: Eclipse libs * if Gradle is also used for other projects, unrelated OFBiz libs * etc. That's why I have decided to have a task like that (initially for OWASP) # Using plugins is certainly more appealing, but * I don't feel an issue to use jQuery plugins because it's just UI and if the plugin is not longer maintained we can still find solutions. Relying on external plugins for our build process is another matter. * I must say I just had a glance to the gradle-repositories-plugin but I wonder how it works, because on GitHub you get a zip with jar inside... Now I have identified another reasons we migh need to extract and copy the external libs we use: if we decide to deliver binary releases. It's not mandatory but most TLPs do that. It can of course be done by a 3rd party and then it's another issue... This is in a relation with http://markmail.org/message/emnu6s5wu2yuyith was (Author: jacques.le.roux): Thanks Taher, Before we discuss this more on the dev ML, just some points: # archiving the Gradle cache is not enough, because you can have not OFBiz related libs in it, for instance on a dev machine * which use Eclipse: Eclipse libs * if Gradle is also used for other projects, unrelated OFBiz libs * etc. That's why I have decided to have a task like that (initially for OWASP) # Using plugins is certainly more appealing, but * I don't feel an issue to use jQuery plugins because it's just UI and if the plugin is not longer maintained we can still find solutions. Relying on external plugins for our build process is another matter. * I must say I just had a glance to the gradle-repositories-plugin but I wonder how it works, because on GitHub you get a zip with jar inside... Now I have identified another reasons we migh need to extract and copy the external libs we use: if we decide to deliver binary releases. It's not mandatory but most TLPs do that. It can of course be done by a 3rd party and then it's another issue... This is in a relation with http://markmail.org/message/emnu6s5wu2yuyith > External library files are not in the OFBiz folder structure. > - > > Key: OFBIZ-7783 > URL: https://issues.apache.org/jira/browse/OFBIZ-7783 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Pierre Smits >Priority: Minor > Fix For: Upcoming Branch > > > With the implementation of the external library download feature of > gradle/gradlew, the external libraries (jar files) are not in the folder > structure any more. > They should reside there, like before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7783) External library files are not in the OFBiz folder structure.
[ https://issues.apache.org/jira/browse/OFBIZ-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15432953#comment-15432953 ] Jacques Le Roux edited comment on OFBIZ-7783 at 8/24/16 9:40 AM: - Hi Jacques, in reply: # so what is wrong with having other libs or eclipse in your dev machine? I don't see where the problem is? # I also don't understand why we would need to download the libraries for binary releases. What is wrong with Gradle downloading whatever you need? This comes back to my initial point above: what is the problem that you are trying to solve exactly? If you can identify it clearly then we won't be discussing things hypothetically and we would pinpoint exactly what you need. What is happening instead is that you're relying on reasons that keep changing like the OWASP plugin and now the binary releases. was (Author: taher): Hi Jacques, in reply: - so what is wrong with having other libs or eclipse in your dev machine? I don't see where the problem is? - I also don't understand why we would need to download the libraries for binary releases. What is wrong with Gradle downloading whatever you need? This comes back to my initial point above: what is the problem that you are trying to solve exactly? If you can identify it clearly then we won't be discussing things hypothetically and we would pinpoint exactly what you need. What is happening instead is that you're relying on reasons that keep changing like the OWASP plugin and now the binary releases. > External library files are not in the OFBiz folder structure. > - > > Key: OFBIZ-7783 > URL: https://issues.apache.org/jira/browse/OFBIZ-7783 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > With the implementation of the external library download feature of > gradle/gradlew, the external libraries (jar files) are not in the folder > structure any more. > They should reside there, like before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7783) External library files are not in the OFBiz folder structure.
[ https://issues.apache.org/jira/browse/OFBIZ-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431217#comment-15431217 ] Jacques Le Roux edited comment on OFBIZ-7783 at 8/22/16 8:43 PM: - Hi Jacques, I suggest to revert it anyway because it needs to be discussed in some detail. We communicated in the past and I made clear objections on adding it. You replied back saying you need it for OWASP where I replied back with a suggestion to use the gradle plugin instead OFBIZ-7930 As for the complexity part, and as I mentioned in other discussions (shortcut tasks, etc ...) this adds problems and complexity in multiple ways: # First, it is inefficient and utilizes disk space needlessly. # If we change anything in the gradle projects structure (move some dependencies down to sub-projects in the future for example, which might be needed for the plugin API not sure) then the task crashes and needs to be updated. So this adds to the brittleness because now you can't chop the system into sub projects without complex logic to combine all the dependencies. # It adds another task, which might seem innocent, but then our build.xml was extremely complex and ant -p did not help a lot because there were so many tasks that it hurts more than helps. This is a classic example of "scope creep". Keep adding unnecessary and minor things which bloats your code base. # Even the way it was written has problems, it does not, for example, belong to the ofbizServer group, instead it more properly belongs to sysadminGroup, which makes it confusing # Also, about your point above where some servers do not have internet access, why would you then copy the runtime libs and not everything? Copying runtime only means you only need a deployment and not building or QA work. # Creating a LAN repository does not get implemented like that! instead you change the repository definition, it's in a completely different place Those are some of the reasons why I suggest to revert and come up with a proper solution if needed. was (Author: taher): Hi Jacques, I suggest to revert it anyway because it needs to be discussed in some detail. We communicated in the past and I made clear objections on adding it. You replied back saying you need it for OWASP where I replied back with a suggestion to use the gradle plugin instead OFBIZ-7930 As for the complexity part, and as I mentioned in other discussions (shortcut tasks, etc ...) this adds problems and complexity in multiple ways: - First, it is inefficient and utilizes disk space needlessly. - If we change anything in the gradle projects structure (move some dependencies down to sub-projects in the future for example, which might be needed for the plugin API not sure) then the task crashes and needs to be updated. So this adds to the brittleness because now you can't chop the system into sub projects without complex logic to combine all the dependencies. - It adds another task, which might seem innocent, but then our build.xml was extremely complex and ant -p did not help a lot because there were so many tasks that it hurts more than helps. This is a classic example of "scope creep". Keep adding unnecessary and minor things which bloats your code base. - Even the way it was written has problems, it does not, for example, belong to the ofbizServer group, instead it more properly belongs to sysadminGroup, which makes it confusing - Also, about your point above where some servers do not have internet access, why would you then copy the runtime libs and not everything? Copying runtime only means you only need a deployment and not building or QA work. - Creating a LAN repository does not get implemented like that! instead you change the repository definition, it's in a completely different place Those are some of the reasons why I suggest to revert and come up with a proper solution if needed. > External library files are not in the OFBiz folder structure. > - > > Key: OFBIZ-7783 > URL: https://issues.apache.org/jira/browse/OFBIZ-7783 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > With the implementation of the external library download feature of > gradle/gradlew, the external libraries (jar files) are not in the folder > structure any more. > They should reside there, like before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
