I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}
Related
I stumbled into an issue where all my unit test classes fail to run, providing the following error:
java.lang.IllegalStateException: Failed to transform class with name <my class name>. Reason: toPrettyPrint (Ljava/lang/String;)Ljava/lang/String; in <my class name>: inconsistent stack height -1
One user commented on the following github thread for powermock, that the same error first happened to them after updating their kotlin plugin:
https://github.com/powermock/powermock/issues/779
After reading this, I have checked with my colleagues to see maybe they have a different kotlin version, and saw that their kotlin plugin version is
203.1.6.0-release-798-AS7717.8, whereas mine is 1.4.32-release-Studio4.1-1.
What I find peculiar abbout this, is that these versions dont follow the same conventions, they look more like two completely different sofware. Is there any way for me to get the same version for my kotlin plugin ?
Any help or clarification is much appreciated, thanks!
They probably just changed the naming scheme for the plugin. Looks like you have one that is about one and a half years out of date.
Anyway, go to File -> Settings -> Languages & Frameworks -> Kotlin and click the Install button.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I'm new to android, currently encountering a seemingly endless supply of random errors while going through tutorials.
Currently, I'm trying to figure out how to set up dependencies. I'm not sure what my dependencies should look like and whether they should be different for different projects, but when I try to import:
classpath 'com.android.tools.build:gradle:3.0.0-alpha9'
I am getting the Error:(30, 0): Could not find method classpath() for arguments [com.android.tools.build:gradle:3.0.0-alpha9] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler message.
Screenshot of the error
How do I set up dependencies for simple projects? Is there a popular, up-to-date source to sort these kinds of issues out?
Thank you for your time.
'com.android.tools.build:gradle:3.0.0-alpha9'is a project dependency, not an module dependency, so you are placing it wrong.
Check your build.gradle project configuration at your project root directory. If there is a 'com.android.tools.build:gradle:3.0.0-alpha9' there as dependency that's all you need.
I got this strange error with gradle, please help me!
/.../app/build/intermediates/res/debug/drawable-xxhdpi-v4/ic_launcher.png:
error: Duplicate file
/.../app/build/intermediates/res/debug/drawable-xxhdpi/ic_launcher.png:
Original is here. The version qualifier may be implied.
Error:Execution failed for task ':app:processDebugResources'.
com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException:
Process 'command '/.../sdk/build-tools/22.0.1/aapt'' finished with non-zero exit value 1
Before it was operating normally, but since I put classpath com.android.tools.build:gradle:1.2.2, this causes me errors
According to Xavier Durochet's explanation on G+, it's due to one of the libraries you use having it's own ic_launcher.png -- which they of course should not (more on that at the bottom).
Chances are the two icons mentioned in the log are different: one is yours and another one is most likely the generic android icon that someone forgot to remove from the library.
To see the offending dependency, hit Ctrl + Shift + N twice (for non-project matching) and type in ic_launcher.png (See the last line on the screenshot)
To work around the issue temporarily, add the -v4 qualifier to your drawable resouce folders (or move just ic_launcher.png to *dpi-v4 if you have your reasons) -- credits to Xavier Durochet for the solution. You can also just rename your icon into something else and make corresponding change to AndroidManifest.xml
The real issue is that the offending lib carries the useless icons. Libraries that have their own resources (like ActionBarSherlock or Google's own Support v7 library) use distinctive naming schemes to avoid collisions with your resource names (abs_, abc_).
Launcher icons have no business being in a library so I encourage you to notify the author of the lib you're using that they forgot to remove the redundant ic_launcher.png files.
Also worth mentioning, as Barry Carroll noted very precisely in the same discussion, this doesn't mean your resources should never overlap those in the library: there are a lot of legit reasons to override a lib's resources with your own (e.g. changing the looks of a library-provided activity) and gradle plugin's resource merging logic does allow this, on purpose.
It's just that in this particular case, the conflict occurs when the lib is behind on the android gradle plugin version (pre-1.2.2) in which case resources end up in two different *dpi folders -- with and without the -v4 qualifier; but they're actually in the same resource "bucket" so the system considers them to be duplicate.
This glitch does bring out the useless ic_launcher.png override (actually, a collision -- due to the glitch) but this situation is not universally bad for other kinds of resources.
I.e. sometimes you intentionally override a lib's resource and this glitch will still cause the error message to pop. This time there's no real problem with resource names, so the temporary solution above or holding back the plugin version are the way to go.
I had the same problem while using a third party library.(RomainPiel/Shimmer-android library on Github)
To solve it, I moved my ic_launcher.png files from drawable folder to mipmap folder. And problem solved.
Downgrading to com.android.tools.build:gradle:1.1.3 sloved my issue
Here is the general method to find the problem:
Run
./gradlew build --stacktrace --info
and You will find the details of errors.
I found my error : a duplicate class caused a TOP-Level error, and remove the duplicated one will solve the problem.
For me a simple "clean project" and "rebuild project" did the trick.
Upgrade to 1.2.3, but ensure that your gradle and buildToolsVersion are identically in your project and the used aars.
In case you use external libs where you can't control the gradle/build version:
Contact the author or check the sources by your own. Some libraries have unused launcher icons which will cause this conflict. Removing this icons will solve your problem. Identically named sources (e.g menu.xml) could also cause this issue in rare cases. An easy workaround would be to rename your ressource.
Just rename ic_launcher.png to something else (e.g ico_launcher.png)
In my case I have added apostrophe s ('s) to strings.xml file.
Do check guys for any such error and remove it will definitely help.
It's so annoying the IDE can't show the error properly rather makes all resources out of sync..
I know it's not the case which is asked in Question but error is quite same i.e. Gradle execution gets failed.
Simply Rename the Image (Rightclick on the Image, Select Refactor and select Rename). It will solve the issue as the Issue has arise as one of the library is also using the image with the same name.
I had the same problem and what follows worked for me:
rename your icon
add tools:replace="android:icon" to your <application> tag in the Manifest
You can try just the first step, but I still had problems when merging the manifest files. This way it should override whatever resource was used in the library.
Follow this link Here
Or
Make change like this.
repositories {
maven {url "https://clojars.org/repo/"}
}
dependencies {
compile 'frankiesardo:icepick:{{latest-version}}'
**provided** 'frankiesardo:icepick-processor:{{latest-version}}'
}
Update to newest gradle plugin 1.5.0 sloved this issue. Update following script in your root build.gradle file
buildscript {
...
dependencies {
classpath 'com.android.tools.build:gradle:1.5.0'
}
...
}
I managed to trigger this problem by inconsistent capitalisation of filename extensions. I had a .jpg image in one drawable directory, but an image of the same filename but .JPG in a different drawable directory. The filenames and directories were right, but the extensions weren't.
I want to simply create a reusable "library" for all my future projects that I'm going to be doing in Haxe. I understand there aren't library projects in Haxe, but rather you would just have a collection of source files somewhere and import them as needed. Right?
I've created a new project using Flambe (a Haxe framework) and opened it in the FlashDevelop IDE. It compiles and runs fine.
Now I want to include my library, so I go into the Project Properties under the "Classpaths" tab and set the relative path to my library. It shows up correctly in the "References", and even has the proper code completion when I type "import ...", yet when I compile it fails on the import line stating: 'Class not found : mlg.Engine'
(mlg being the package, and Engine being the class/type)
Is there anything I'm missing?
I think (i may be wrong) that flashdevelop "references" are just autocompletion and not actually passed to the compiler.
I'm not sure what's the "right" way to do it, but I can tell you what I've done (I made a few helper classes for flambe too :P): I simply created a "fake" haxelib, I created HaxeToolkit/haxe/lib/[name]/git, and in [name] i created a .current file that contains "git".
Then on flashdevelop you have to add it as a library (Project settings -> Compiler options -> Libraries).
Note: there are probably other/better ways to do it.