I use this two packages:
barcode_scan: ^0.0.3
fluttie: ^0.3.0
When I try to run my application, I get the following error:
D8: Program type already present: android.support.v4.app.INotificationSideChannel
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:transformDexArchiveWithExternalLibsDexMergerForDebug'.
com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives: /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/29.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/111.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/126.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/57.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/160.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/63.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/56.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/64.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/28.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/91.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/81.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/27.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/156.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/59.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/157.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/141.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/65.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/2.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/58.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/3.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/101.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/94.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/159.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/30.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/116.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/60.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/95.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/158.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/151.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/1.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/136.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/146.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/76.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/92.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/131.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/86.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/71.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/62.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/0.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/93.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/106.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/121.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/9.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/37.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/10.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/44.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/38.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/8.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/12.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/43.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/13.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/26.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/21.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/39.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/33.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/14.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/20.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/15.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/45.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/32.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/24.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/16.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/31.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/40.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/25.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/22.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/34.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/17.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/35.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/18.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/42.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/19.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/23.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/36.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/11.jar, /Users/rhuka/repository/github/learn/flutter/flutter_lottie_signup/build/app/intermediates/transforms/dexBuilder/debug/41.jar
Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.
Program type already present: android.support.v4.app.INotificationSideChannel
Seems to me that both of them use the same class android.support.v4.app.INotificationSideChannel because when I try to use only one of them everything works fine. But I need both on my application. How can I ignore the duplicated classes or just solve this?
I'm facing the same sort of conflict with qr_code_scanner the solution is to delete or change classes for one of them I don't know if flutter has built-in method to handle this sort of conflicts.
but what you can try is to get package from git repo do the changes push the code to your own repo and pub get from your own git repo:
dependencies:
fluttie:
git:
url: https://github.com/...
ref: main
Related
I was just struggling with the error below in my IDE for a frustratingly-long time:
ESLint: Error: Failed to load config "#vue/typescript" to extend from.
After a lot of Googling and running commands I found online, I eventually found that what (seemed to) fix the problem was running this:
yarn add -D #vue/eslint-config-typescript
My question is: How was I supposed to figure that out? Is there some website or service or something where I could have searched for #vue/typescript and found out that the package I needed to install was #vue/eslint-config-typescript?
Ok, I figured it out: in the ESLint docs, it says that basically that the part after the forward-slash should be understood to always start with eslint-plugin:
They show the following examples:
"plugins": [
"jquery", // means eslint-plugin-jquery
"#jquery/jquery", // means #jquery/eslint-plugin-jquery
"#foobar" // means #foobar/eslint-plugin
]
I'm trying to run go build command for my project but it exits with below error.
alpha#GHOST-RIDER:~/GoWorkspace/src/github.com/hyperledger/firstproject$ go build
# github.com/hyperledger/fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations
../fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations/system.go:227:23: not enough arguments in call to s.statsd.SendLoop
have (<-chan time.Time, string, string)
want (context.Context, <-chan time.Time, string, string)
Any help would be appreciated.
As per code fabric is using the different version of this library: github.com/go-kit/kit/metrics/statsd. If you follow the System struct's statsd attribute, you can reach the reference on imports.
In master branch of this lib, SendLoop function requires 4 attributes, so that's the root cause. So this causes error when you compile on your local environment.
I had the same issue and worked around it by checking out a tag of library as below:
cd $GOPATH/src/github.com/go-kit/kit
git fetch --tags
git checkout v0.8.0
found a solution on the hyperledger-fabric-go-sdk group chat.
Add context.Background() in s.statsd.SendLoop like below
s.statsd.SendLoop(context.Background(), s.sendTicker.C, network, address)
in fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations/system.go file at line 227.
I had a same issue, my solution worked and don't need edit fabric source code.
specify github.com/go-kit/kit to v0.8.0, modify go.mod:
replace github.com/go-kit/kit => github.com/go-kit/kit v0.8.0 // you specific version
require (
... ...
// Maybe other version, go mod tidy update automatically, don't care it.
github.com/go-kit/kit v0.9.0 // indirect
... ...
)
then it worked.
Error:A problem occurred configuring root project 'app_name'.
> Could not resolve all dependencies for configuration ':_debugCompile'.
> Could not find com.crashlytics.sdk.android:answers-shim:0.0.3.
Searched in the following locations:
https://repo1.maven.org/maven2/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.pom
https://repo1.maven.org/maven2/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.aar
file:/Users/arun/repos/app_name/libs/answers-shim-0.0.3.aar
file:/Users/arun/repos/app_name/libs/answers-shim.aar
https://maven.fabric.io/public/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.pom
https://maven.fabric.io/public/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.aar
file:/Users/arun/Library/Android/sdk/extras/android/m2repository/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.pom
file:/Users/arun/Library/Android/sdk/extras/android/m2repository/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.aar
file:/Users/arun/Library/Android/sdk/extras/google/m2repository/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.pom
file:/Users/arun/Library/Android/sdk/extras/google/m2repository/com/crashlytics/sdk/android/answers-shim/0.0.3/answers-shim-0.0.3.aar
Required by:
:app_name:unspecified > io.branch.sdk.android:library:1.14.2
branch-io originally was io.branch.sdk.android:library:1+ I then tried
io.branch.sdk.android:library:1.14.1 and io.branch.sdk.android:library:1.14.2 with the same error.
Any ideas what is happening?
com.crashlytics.sdk.android:answers-shim:0.0.3 isn't available on mavenCentral. Add jcenter to your repository section.
ref: https://bintray.com/fabric/fabric/com.crashlytics.sdk.android%3Aanswers-shim/view
Example:
repositories {
jcenter()
}
If you don't plan to use the Fabric Answers integration, and don't want to import the answers-shim, just import your project as follows:
replace io.branch.sdk.android:library:1.14.1 with
implementation ('io.branch.sdk.android:library:3.+') {
exclude module: 'answers-shim'
}
Source - https://github.com/BranchMetrics/android-branch-deep-linking
When I first discovered webJars a few months ago I was super-skeptical that it would be be a viable way means of handling client-side dependencies given the enormous complexity of some of these builds/buildsystems, and given the frequency that js files are published. The second concern was of course not well-founded but I feel vindicated on the first after spending almost 36 hours now trying in vain to get about 10 scss/css/less-type webJars and 8 JS webJars to live under one jsDependencies roof.
What I found as that by the time you reach JS dependency 3, 4, or 5,you start getting into a ridiculous timekill loop:
1. "Oh nos! fastOptJS failed because there was some random file that was also named the same as a dependency in the webjar!"
[trace] Stack trace suppressed: run last client/compile:resolvedJSDependencies for the full output.
[error] (client/compile:resolvedJSDependencies) org.scalajs.core.tools.jsdep.JSLibResolveException: Some references to JS libraries could not be resolved:
[error] - Ambiguous reference to a JS library: bootstrap.min.js
[error] Possible paths found on the classpath:
[error] - META-INF/resources/webjars/bootstrap/3.3.6/js/bootstrap.min.js
[error] - META-INF/resources/webjars/bootstrap3-dialog/1.34.4/examples/assets/bootstrap/js/bootstrap.min.js
[error] originating from: client:compile, client:compile, client:compile, client:compile
[error] - Ambiguous reference to a JS library: bootstrap.js
[error] Possible paths found on the classpath:
[error] - META-INF/resources/webjars/bootstrap3-dialog/1.34.4/examples/assets/bootstrap/js/bootstrap.js
[error] - META-INF/resources/webjars/bootstrap/3.3.6/js/bootstrap.js
[error] originating from: client:compile, client:compile, client:compile, client:compile
2. I know what to do! I'll add a version to the defined js!
lazy val webjarbs = "org.webjars" % "bootstrap" % version.bootstrap / s"${version.bootstrap}/bootstrap.js" minified s"${version.bootstrap}/bootstrap.min.js" dependsOn "jquery.js" commonJSName "bootstrap"
3. "Oh no! fastOptJS failed!"
[trace] Stack trace suppressed: run last client/compile:resolvedJSDependencies for the full output.
[error] (client/compile:resolvedJSDependencies) org.scalajs.core.tools.jsdep.JSLibResolveException: Some references to JS libraries could not be resolved:
[error] - Missing JS library: 3.3.6/bootstrap.js
[error] originating from: client:compile, client:compile, client:compile, client:compile
[error] - Missing JS library: 3.3.6/bootstrap.min.js
[error] originating from: client:compile, client:compile, client:compile, client:compile
gg boys.
This goes over and over and around and around, and then I have to start doing
lazy val bs_sidebar = ( "org.webjars" % "bootstrap-sidebar" % version.bs_sidebar intransitive()) / "js/sidebar.js" dependsOn(s"bootstrap.js", s"bootstrap.min.js")
and now I'm not really even using the webjar, but it has a jsdependency named X and I cannot change that...
Question
Hmmm? What if I just did what I used to do but build the dependencies without the app into some gigantic file, or set of files, and then feed that into the build? I have a proof of concept from online and I got it work (I think it was https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala ) which almost worked, and gave me the idea.
I know npm works a lot better than sbt, and I can still get it into my package... what's the downside, and am I missing something about sbt?
I agree with you. Once an application starts having non-trivial dependencies on JavaScript libraries, jsDependencies does not scale. This is mostly because WebJars are missing critical features (just as transitive dependencies), but also because jsDependencies was not a mechanism designed to scale.
As time passed, users have asked for more and more features of jsDependencies, because they want to use it as their true app-scale (whatever that means) dependency mechanism. As a result, we've been patching more and more features/hacks on top of jsDependencies. The result is not the prettiest thing in the world, and it definitely has shortcomings.
I would actually encourage using npm to resolve your dependencies, especially if you are familiar with it and know how to integrate it into your workflow.
The principal advantage to using web jars, in my opinion, is not having to use npm. Plus, they go through the usual maven resolution / download process, so while it isn't perfect, it's only one pipeline of breakage instead of two.
Regardless, they can be painful. I've got about 30 dependencies in my scala.js app, and they are mostly managed with web jars. I have found that, in general, I get better results using npm webjars vs. bower webjars, and it is folly to attempt to rely on web jar transitive dependencies.
My jsDependencies tend to look like this:
("org.webjars" % "morrisjs" % "0.5.1" intransitive ())
/ "morris.js"
minified "morris.min.js"
dependsOn "2.1.2/raphael.js",
("org.webjars" % "raphaeljs" % "2.1.2-1" intransitive ())
/ "2.1.2/raphael.js"
minified "2.1.2/raphael-min.js"
The first thing to note is the version number mangled onto basically everything that ever gets depended on. If it gets used much, I extract the version out into a variable. The second thing is the intransitive() annotation. While I can sometimes get away without it, I find that being explicit keeps things working and my hair in place.
I tend to stick to front-end friendly packages like react and angular. Some of the new react libraries have dozens of transitive dependencies and attempting to use them would be painful. I avoid those =p
UPDATE 8/6:
The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.
We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.
Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?
Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar
then the false(?) error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)
Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??
Original post:
I am intermittently getting an error when running a number of different Groovy scripts which all share an identical #Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:
#GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') #Grapes([
#Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
#Grab('commons-lang:commons-lang:2.3'),
#Grab('log4j:log4j:1.2.16'),
#Grab('gpars:gpars:0.12'),
#Grab('jsr166y:jsr166y:1.7.0'),
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
#Grab('org.apache.commons:commons-collections:3.2.1'),
#Grab('org.apache.httpcomponents:httpclient:4.2.2'),
#Grab('org.apache.httpcomponents:httpcore:4.2.3'),
#Grab('org.cyberneko.html:nekohtml:1.9.17'),
#Grab('xerces:xercesImpl:2.11.0'),
]) #GrabConfig(systemClassLoader = true)
Then the error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems:
1. Repository unreachable
2. Jar file doesn’t exist
However, in the artifactory logs, I've proven that the file is actually being downloaded:
*Artifactory did accept the request for download:
2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] libs-release-local:com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar for anonymous/165.226.40.155.
*Artifactory did deliver jar:
20140717075820|156|REQUEST|165.226.40.155|non_authenticated_user|GET|/libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar|HTTP/1.1|200|1276695
The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.
For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.
Questions:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
Does putting a try / catch block around the #Grab statements seem like a good idea? Or will that just hide the real problem?
thanks in advance!!!!
I think I finally figured out the answer to my own question.
I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.
Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.
I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:
-Dgrape.root=D:\Temp\grapeCache
UPDATE 8/19:
Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:
-Dgrape.config=D:\Temp\myGrapeConfig.xml
which had these contents:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
</chain>
</resolvers>
</ivysettings>
ALSO:
For completeness (further steps):
In Jenkins GUI, update the job(s):
a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6
b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):
-Dgrape.config=D:\Software\SfGrapeConfig.xml
Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
If you get this or a similar error:
"could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"
Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)