Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Minor
    • Resolution: Implemented
    • Affects Version/s: Trunk
    • Fix Version/s: 16.11.01
    • Component/s: framework
    • Labels:
      None

      Description

      As I warned at https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check it's currently difficult to separate the OFBiz jars from other jars in the .gradle\caches contains which may contain jars unrelated to OFBiz. Notably Eclipse jars if you use the Gradle Eclipse task and more if you use Gradle for other reasons than OFBiz.

      I did not find yet a way to avoid to have all external jars in .gradle\caches and I wonder if it's even possible. What I would like to have is the external jars mandatory for OFBiz to work in an isolated place. For instance a sub folder of the main Gradle build folder. I picked $buildDir/externalJars.

      1. OFBIZ-7534.patch
        0.9 kB
        Taher Alkhateeb

        Issue Links

          Activity

          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Taher!

          Your slightly modified patch is in trunk at revision: 1759250

          I have simply formatted the "if(" to "if ("

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Taher! Your slightly modified patch is in trunk at revision: 1759250 I have simply formatted the "if(" to "if ("
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Taher, I'll commit your patch now and create a new issue for the rest of the work, thanks!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Taher, I'll commit your patch now and create a new issue for the rest of the work, thanks!
          Hide
          taher Taher Alkhateeb added a comment - - edited

          Oh okay good idea.

          We have libraries already in build.gradle that I think should be deleted (guava among others for example). You might want to start over there.

          Show
          taher Taher Alkhateeb added a comment - - edited Oh okay good idea. We have libraries already in build.gradle that I think should be deleted (guava among others for example). You might want to start over there.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          No no, I mean I'll do that once to help the task of pruning uselessy downloaded libs by Gradle; ie those which are reported now by OWASP-DC but we had not just before we introduced Grale. They are most likely not needed...

          Show
          jacques.le.roux Jacques Le Roux added a comment - No no, I mean I'll do that once to help the task of pruning uselessy downloaded libs by Gradle; ie those which are reported now by OWASP-DC but we had not just before we introduced Grale. They are most likely not needed...
          Hide
          taher Taher Alkhateeb added a comment -

          That might be an overkill Jacques. This would substantially complicate the script for something which very few people would actually use.

          Also, the plugin is reliant on mavenCentral, not jcenter. So all that you need to do is delete $HOME/.m2 and you're done (unless you have other things that depend on mavenCentral). But even if not the case, I think what you are trying to accomplish would be a lot of work for little value.

          Show
          taher Taher Alkhateeb added a comment - That might be an overkill Jacques. This would substantially complicate the script for something which very few people would actually use. Also, the plugin is reliant on mavenCentral, not jcenter. So all that you need to do is delete $HOME/.m2 and you're done (unless you have other things that depend on mavenCentral). But even if not the case, I think what you are trying to accomplish would be a lot of work for little value.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Taher, that sounds ilke a good start. And maybe also a way to more easily prune the useless libs Gradle automatically downloads. This by comparing with the pre Gradle report version... Stay tuned...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Taher, that sounds ilke a good start. And maybe also a way to more easily prune the useless libs Gradle automatically downloads. This by comparing with the pre Gradle report version... Stay tuned...
          Hide
          taher Taher Alkhateeb added a comment - - edited

          Hi Jacques. In order to test things I am attaching my work for your review.

          Essentially, you just have to pass a flag to enable the plugin. The dependencies for OWASP will only download if you pass the flag, otherwise it will not recognize any OWASP tasks.

          To test it, run an OWASP task from the command line: e.g.

          ./gradlew -PenableOwasp dependencyCheck
          
          Show
          taher Taher Alkhateeb added a comment - - edited Hi Jacques. In order to test things I am attaching my work for your review. Essentially, you just have to pass a flag to enable the plugin. The dependencies for OWASP will only download if you pass the flag, otherwise it will not recognize any OWASP tasks. To test it, run an OWASP task from the command line: e.g. ./gradlew -PenableOwasp dependencyCheck
          Hide
          taher Taher Alkhateeb added a comment -

          okay, started a thread on -> http://markmail.org/message/xnl2lw3pix2sm5q3

          If no one objects I will commit.

          Show
          taher Taher Alkhateeb added a comment - okay, started a thread on -> http://markmail.org/message/xnl2lw3pix2sm5q3 If no one objects I will commit.
          Hide
          taher Taher Alkhateeb added a comment -

          Yeah, it is better to discuss it in ML just to be extra sure. The work is ready to be committed without any problems. I'll start a thread and we can get lazy consensus if no one replies.

          Show
          taher Taher Alkhateeb added a comment - Yeah, it is better to discuss it in ML just to be extra sure. The work is ready to be committed without any problems. I'll start a thread and we can get lazy consensus if no one replies.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          This was my own initiative I started to use OWASP-DC around end of 2013. I committed related stuff end of 2015 and then created the related page in wiki. So far nobody disagreed, so I take that as a lazy consensus. If there was a better free tool I'd use it. You might start a discussion on the dev ML if you think it's worth it.

          Show
          jacques.le.roux Jacques Le Roux added a comment - This was my own initiative I started to use OWASP-DC around end of 2013. I committed related stuff end of 2015 and then created the related page in wiki. So far nobody disagreed, so I take that as a lazy consensus. If there was a better free tool I'd use it. You might start a discussion on the dev ML if you think it's worth it.
          Hide
          taher Taher Alkhateeb added a comment -

          Okay, I have a clean working solution now that does not affect users who do not want the OWASP plugin. Before I go ahead and commit this, I need to confirm that we have consensus on using OWASP. Is that something that we discussed before in ML or that is recommended by default or something like that?

          Show
          taher Taher Alkhateeb added a comment - Okay, I have a clean working solution now that does not affect users who do not want the OWASP plugin. Before I go ahead and commit this, I need to confirm that we have consensus on using OWASP. Is that something that we discussed before in ML or that is recommended by default or something like that?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Taher, much appreciated.

          1. https://github.com/jeremylong/dependency-check-gradle#what-if-my-project-includes-multiple-sub-project-how-can-i-use-this-plugin-for-each-of-them-including-the-root-project
          2. The purpose is two-fold.
            1. To inform our users about possible vulnerabilities in our external dependencies
            2. To fix them as much as possible before exposing them to public
              Committers are more concerned, but everybody can help
          3. I put it here https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check It's actually reports from versions in the svn repo
            I want to have a report for each releases and even for each supported branches, including trunk of course.
            Once you have the report it's nice to publish it. But before it should be uised to fix possible vulnerabilities in our external dependencies.
            Note that the suppress file is needed because OWASP-DC report a lot of false positive initially. AFAIK there is no other such free tools.
          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Taher, much appreciated. https://github.com/jeremylong/dependency-check-gradle#what-if-my-project-includes-multiple-sub-project-how-can-i-use-this-plugin-for-each-of-them-including-the-root-project The purpose is two-fold. To inform our users about possible vulnerabilities in our external dependencies To fix them as much as possible before exposing them to public Committers are more concerned, but everybody can help I put it here https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check It's actually reports from versions in the svn repo I want to have a report for each releases and even for each supported branches, including trunk of course. Once you have the report it's nice to publish it. But before it should be uised to fix possible vulnerabilities in our external dependencies. Note that the suppress file is needed because OWASP-DC report a lot of false positive initially. AFAIK there is no other such free tools.
          Hide
          taher Taher Alkhateeb added a comment - - edited

          Hi Jacques,

          You made a comment about being stuck in this JIRA, so I'll try to help.

          So I think the solution to your problem here is to avoid loading the plugin except when the proper task is activated. So you need to have a condition to check whether it is appropriate, and if yes, load the plugin and activate the security task. This way, normal users do not worry about downloading the extra dependencies while at the same time you can activate the OWASP plugin.

          So, to help you in implementing this, there are a few questions first:

          1. Can you please provide the code snippet which activated the plugin, I forgot it. We can use that as a starting point
          2. What is the purpose here and who calls this task? is it committers, is it everyone? this makes it relevant to which script does it belong to (master or /tools perhaps)
          3. What do you do with the output? just display it?
          Show
          taher Taher Alkhateeb added a comment - - edited Hi Jacques, You made a comment about being stuck in this JIRA, so I'll try to help. So I think the solution to your problem here is to avoid loading the plugin except when the proper task is activated. So you need to have a condition to check whether it is appropriate, and if yes, load the plugin and activate the security task. This way, normal users do not worry about downloading the extra dependencies while at the same time you can activate the OWASP plugin. So, to help you in implementing this, there are a few questions first: Can you please provide the code snippet which activated the plugin, I forgot it. We can use that as a starting point What is the purpose here and who calls this task? is it committers, is it everyone? this makes it relevant to which script does it belong to (master or /tools perhaps) What do you do with the output? just display it?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          OK I removed it at 1754524

          I agree this is taking too long, and we need to find a way to have it loaded only when needed. At least it works and is the right solution.

          Show
          jacques.le.roux Jacques Le Roux added a comment - OK I removed it at 1754524 I agree this is taking too long, and we need to find a way to have it loaded only when needed. At least it works and is the right solution.
          Hide
          taher Taher Alkhateeb added a comment -

          Okay, this is taking too long on my computer, and it seems to be such a low priority thing Jacques. I really think it is better to revert and find a cleaner way to incorporate this. It's really not worth downloading so many new dependencies just to activate this tool. Totally not worth it to users.

          Show
          taher Taher Alkhateeb added a comment - Okay, this is taking too long on my computer, and it seems to be such a low priority thing Jacques. I really think it is better to revert and find a cleaner way to incorporate this. It's really not worth downloading so many new dependencies just to activate this tool. Totally not worth it to users.
          Hide
          taher Taher Alkhateeb added a comment - - edited

          One thing I notice is that this plugin downloads a LOT of dependencies which are not essential. This will bother a lot of users, I would really rather see it load only upon necessity.

          Show
          taher Taher Alkhateeb added a comment - - edited One thing I notice is that this plugin downloads a LOT of dependencies which are not essential. This will bother a lot of users, I would really rather see it load only upon necessity.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Taher, I'll consider this next week!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Taher, I'll consider this next week!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Implemented at r1754508

          Show
          jacques.le.roux Jacques Le Roux added a comment - Implemented at r1754508
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Using the owasp dependencycheck Gradle plugin is so far a much better solution than what I proposed, thanks Taher!

          We will have though to see how to add entries in the equivalent of the suppress.xml file.

          For now I close this issue.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Using the owasp dependencycheck Gradle plugin is so far a much better solution than what I proposed, thanks Taher! We will have though to see how to add entries in the equivalent of the suppress.xml file. For now I close this issue.
          Hide
          taher Taher Alkhateeb added a comment -

          One idea comes to my mind is not to load the plugin unless you pass a project property. It is easy to code that during the configuration phase of Gradle and it has the added benefit of hiding this stuff away from regular users and reducing the help menu. Another idea is to create the plugin in a subproject (/tools for example) and do whatever you want in there. This would also have the added benefit of moving all unwanted tasks to it. For example, we move svnInfoFooter, gitInfoFooter, copyDtds also to that build.gradle away from the master build script.

          Food for thought!

          Show
          taher Taher Alkhateeb added a comment - One idea comes to my mind is not to load the plugin unless you pass a project property. It is easy to code that during the configuration phase of Gradle and it has the added benefit of hiding this stuff away from regular users and reducing the help menu. Another idea is to create the plugin in a subproject (/tools for example) and do whatever you want in there. This would also have the added benefit of moving all unwanted tasks to it. For example, we move svnInfoFooter, gitInfoFooter, copyDtds also to that build.gradle away from the master build script. Food for thought!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I tried the owasp depend. check plugin. It's very easy and works well. But the result needs a lot of entries in the owasp depend. check suppress file (not sure if it exists and how it used yet, maybe this https://github.com/danielsomerfield/gradle-cve-dependency-check I have to try)
          For instance we don't care about the eclipse jars, etc.

          Next week, not a priority...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I tried the owasp depend. check plugin. It's very easy and works well. But the result needs a lot of entries in the owasp depend. check suppress file (not sure if it exists and how it used yet, maybe this https://github.com/danielsomerfield/gradle-cve-dependency-check I have to try) For instance we don't care about the eclipse jars, etc. Next week, not a priority...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Ah that's quite a relief it seems, I'll try it, thanks Taher!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Ah that's quite a relief it seems, I'll try it, thanks Taher!
          Hide
          taher Taher Alkhateeb added a comment - - edited

          Yeah I am struggling to understand the purpose exactly so appreciate your help in clarifying it a bit. So If my understanding is correct, you are worried about having unwanted jars which could pose a security threat to the system right?

          If that is the case, why not immediately use the owasp plugin from gradle? https://plugins.gradle.org/plugin/org.owasp.dependencycheck

          Show
          taher Taher Alkhateeb added a comment - - edited Yeah I am struggling to understand the purpose exactly so appreciate your help in clarifying it a bit. So If my understanding is correct, you are worried about having unwanted jars which could pose a security threat to the system right? If that is the case, why not immediately use the owasp plugin from gradle? https://plugins.gradle.org/plugin/org.owasp.dependencycheck
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          No need to rush on this, I'll try again next week...

          Show
          jacques.le.roux Jacques Le Roux added a comment - No need to rush on this, I'll try again next week...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I thought it was explained in the description

          Show
          jacques.le.roux Jacques Le Roux added a comment - I thought it was explained in the description
          Hide
          taher Taher Alkhateeb added a comment -

          Hi Jacques,

          I will try to help out. I am still however trying to understand the answer for my question above?

          Show
          taher Taher Alkhateeb added a comment - Hi Jacques, I will try to help out. I am still however trying to understand the answer for my question above?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Taher,

          Yes in my last version, inspired by Pierre somewhere, I added the pluginLibsRuntime, here is my last take

          Index: build.gradle
          ===================================================================
          --- build.gradle	(revision 1754437)
          +++ build.gradle	(working copy)
          @@ -580,6 +580,29 @@
                   report(format:'frames', todir:'./runtime/logs/test-results/html')
               }
           }
          +
          +task copyExternalJars(group: sysadminGroup, description: 'Copy all external jars in the $buildDir/externalJars folder') {
          +    String externalJarsDirString = "$buildDir/externalJars"
          +    File extJarsDir = file(externalJarsDirString)
          +    delete extJarsDir
          +    copy {
          +        from {
          +            configurations.compile
          +            configurations.runtime
          +        }
          +        into externalJarsDirString
          +        exclude "**/org.eclipse*" // for now I don't exclude JDBC drivers are they were added temporarily
          +    }
          +    subprojects.each { p ->
          +        copy {
          +            from {
          +                p.configurations.pluginLibsCompile
          +                p.configurations.pluginLibsRuntime
          +            }
          +            into externalJarsDirString
          +        }
          +    }
          +}
           /*
            * TODO replace this code with something more declarative.
            * We are using it so that if tests fail we still get HTML reports
          @@ -636,6 +659,11 @@
               delete 'ofbiz.jar'
           }
          
          +task cleanExternalJars(group: cleanupGroup, description: 'Delete the $buildDir/externalJars folder') {
          +    delete "$buildDir/externalJars"
          +}
          +
          +
           def cleanTasks = getTasksMatchingRegex(/^clean.+/)
           task cleanAll(group: cleanupGroup, dependsOn: [cleanTasks, clean]) {
               description 'Execute all cleaning tasks.'
          

          But I'm blocked for 2 days by something extremely hard to understand. I had already "delete extJarsDir" in copyExternalJars, and copyExternalJars worked quite well. So I created its cleanExternalJars counterpart and used it once, alone (ie not with cleanAll). Since then, when I run copyExternalJars, I'm blocked with an always "UP TO DATE" . I searched for a solution on the Net and got some ideas:

          1. Use use --rerun-tasks or/and "outputs.upToDateWhen {false}"
            from https://stackoverflow.com/questions/7289874/resetting-the-up-to-date-property-of-gradle-tasks
            https://stackoverflow.com/questions/15137271/what-does-up-to-date-in-gradle-indicate explains "UP TO DATE"
            and I did not try yet the solution at https://stackoverflow.com/questions/29599011/up-to-date-gradle-task-status-when-it-has-no-output
          2. Use --refresh-dependencies as suggested
            at https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies,
            did no try "resolutionStrategy.cacheChangingModulesFor 0, 'seconds' " yet
          3. delete ALL the .gradle folders as suggested at https://discuss.gradle.org/t/copy-task-fails-erroneously-claiming-it-is-up-to-date-with-gradle-1-8/2166/5
            which led me to pending https://issues.gradle.org/browse/GRADLE-2898

          All to no avail, I was really surprised after deleting ALL the .gradle folders (ie ~/.gradle folder and the .gradle folder from the parent project directory) I may have missed something. I checked there is no .gradle folder in the Windows roaming stuff. I know that well because I got bitten more than once by the roaming stuff in other cases. If interested (I doubt ) see
          https://superuser.com/questions/312136/how-does-the-roaming-folder-work
          or https://askleo.com/whats-the-appdata-roaming-folder/
          or (more technical) https://en.wikipedia.org/wiki/Roaming_user_profile

          I'll try again to delete ALL the .gradle folders because I don't see how this could not work, else it's really bad :/

          Show
          jacques.le.roux Jacques Le Roux added a comment - Taher, Yes in my last version, inspired by Pierre somewhere, I added the pluginLibsRuntime, here is my last take Index: build.gradle =================================================================== --- build.gradle (revision 1754437) +++ build.gradle (working copy) @@ -580,6 +580,29 @@ report(format:'frames', todir:'./runtime/logs/test-results/html') } } + +task copyExternalJars(group: sysadminGroup, description: 'Copy all external jars in the $buildDir/externalJars folder') { + String externalJarsDirString = "$buildDir/externalJars" + File extJarsDir = file(externalJarsDirString) + delete extJarsDir + copy { + from { + configurations.compile + configurations.runtime + } + into externalJarsDirString + exclude "**/org.eclipse*" // for now I don't exclude JDBC drivers are they were added temporarily + } + subprojects.each { p -> + copy { + from { + p.configurations.pluginLibsCompile + p.configurations.pluginLibsRuntime + } + into externalJarsDirString + } + } +} /* * TODO replace this code with something more declarative. * We are using it so that if tests fail we still get HTML reports @@ -636,6 +659,11 @@ delete 'ofbiz.jar' } +task cleanExternalJars(group: cleanupGroup, description: 'Delete the $buildDir/externalJars folder') { + delete "$buildDir/externalJars" +} + + def cleanTasks = getTasksMatchingRegex(/^clean.+/) task cleanAll(group: cleanupGroup, dependsOn: [cleanTasks, clean]) { description 'Execute all cleaning tasks.' But I'm blocked for 2 days by something extremely hard to understand. I had already "delete extJarsDir" in copyExternalJars, and copyExternalJars worked quite well. So I created its cleanExternalJars counterpart and used it once, alone (ie not with cleanAll). Since then, when I run copyExternalJars, I'm blocked with an always "UP TO DATE" . I searched for a solution on the Net and got some ideas: Use use --rerun-tasks or/and "outputs.upToDateWhen {false}" from https://stackoverflow.com/questions/7289874/resetting-the-up-to-date-property-of-gradle-tasks https://stackoverflow.com/questions/15137271/what-does-up-to-date-in-gradle-indicate explains "UP TO DATE" and I did not try yet the solution at https://stackoverflow.com/questions/29599011/up-to-date-gradle-task-status-when-it-has-no-output Use --refresh-dependencies as suggested at https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies , did no try "resolutionStrategy.cacheChangingModulesFor 0, 'seconds' " yet delete ALL the .gradle folders as suggested at https://discuss.gradle.org/t/copy-task-fails-erroneously-claiming-it-is-up-to-date-with-gradle-1-8/2166/5 which led me to pending https://issues.gradle.org/browse/GRADLE-2898 All to no avail, I was really surprised after deleting ALL the .gradle folders (ie ~/.gradle folder and the .gradle folder from the parent project directory) I may have missed something. I checked there is no .gradle folder in the Windows roaming stuff. I know that well because I got bitten more than once by the roaming stuff in other cases. If interested (I doubt ) see https://superuser.com/questions/312136/how-does-the-roaming-folder-work or https://askleo.com/whats-the-appdata-roaming-folder/ or (more technical) https://en.wikipedia.org/wiki/Roaming_user_profile I'll try again to delete ALL the .gradle folders because I don't see how this could not work, else it's really bad :/
          Hide
          taher Taher Alkhateeb added a comment -

          Hi Jacques,

          We can definitely come up with a solution and yours has most of it (you need to add pluginLibsRuntime as well).

          However, I have a question, why do you want the Jars in the first place? Why do you want them isolated? What is the purpose?

          Show
          taher Taher Alkhateeb added a comment - Hi Jacques, We can definitely come up with a solution and yours has most of it (you need to add pluginLibsRuntime as well). However, I have a question, why do you want the Jars in the first place? Why do you want them isolated? What is the purpose?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I quote my comment here for convenience

          Actually I needed more the compile part, but I think I'll also add the runtime one but w/o the JDBC drivers because I agree we should not have them by default loaded. I explained why at https://issues.apache.org/jira/browse/OFBIZ-7808?focusedCommentId=15393595&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15393595

          I'll maybe have to exclude more libs, working on it with OWASP Dependencies checker will let me know.

          Show
          jacques.le.roux Jacques Le Roux added a comment - I quote my comment here for convenience Actually I needed more the compile part, but I think I'll also add the runtime one but w/o the JDBC drivers because I agree we should not have them by default loaded. I explained why at https://issues.apache.org/jira/browse/OFBIZ-7808?focusedCommentId=15393595&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15393595 I'll maybe have to exclude more libs, working on it with OWASP Dependencies checker will let me know.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I replied there, still a WIP here...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I replied there, still a WIP here...
          Hide
          pfm.smits Pierre Smits added a comment -

          Hi Jacques Le Roux,

          What is the difference of this issue when compared to OFBIZ-7783?

          Show
          pfm.smits Pierre Smits added a comment - Hi Jacques Le Roux , What is the difference of this issue when compared to OFBIZ-7783 ?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I came with this Gradle task so far

          task copyExternalJars(group: sysadminGroup, description: 'Copy all external jars in the $buildDir/externalJars folder') {
              String externalJarsDirString = "$buildDir/externalJars"
              File extJarsDir = file(externalJarsDirString)
              delete extJarsDir
              copy {
                  from configurations.compile
                  into externalJarsDirString
                  exclude "**/org.eclipse*"
              }
              subprojects.each { p ->
                  copy {
                      from p.configurations.pluginLibsCompile
                      into externalJarsDirString
                  }
              }
          }
          

          I'm not yet quite sure it does all right, but it's a 1st step that I'll revisit. Of course, all comments are welcome

          Show
          jacques.le.roux Jacques Le Roux added a comment - I came with this Gradle task so far task copyExternalJars(group: sysadminGroup, description: 'Copy all external jars in the $buildDir/externalJars folder') { String externalJarsDirString = "$buildDir/externalJars" File extJarsDir = file(externalJarsDirString) delete extJarsDir copy { from configurations.compile into externalJarsDirString exclude "**/org.eclipse*" } subprojects.each { p -> copy { from p.configurations.pluginLibsCompile into externalJarsDirString } } } I'm not yet quite sure it does all right, but it's a 1st step that I'll revisit. Of course, all comments are welcome

            People

            • Assignee:
              taher Taher Alkhateeb
              Reporter:
              jacques.le.roux Jacques Le Roux
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development