[
https://issues.apache.org/jira/browse/OFBIZ-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398908#comment-15398908
]
Jacques Le Roux commented on OFBIZ-7930:
----------------------------------------
Taher,
Yes in my last version, inspired by Pierre somewhere, I added the
pluginLibsRuntime, here is my last take
{code}
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.'
{code}
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 :/
> Copy external jars in OFBiz $buildDir/externalJars for (at least) dependency
> check
> ----------------------------------------------------------------------------------
>
> Key: OFBIZ-7930
> URL: https://issues.apache.org/jira/browse/OFBIZ-7930
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
> Affects Versions: Trunk
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
