I have a groovy project in IntelliJ IDEA that uses logback.groovy. It's in src/main/resources so that it ends up in the classpath of the project, but IDEA compiles it into logback.class. Logback expects this to be in .groovy format, so this won't do. Is there a way to prevent this behavior? I just want logback.groovy in my classpath for running unit tests and webapp debugging.
IDEA 13 now supports new types of directory assignments under your content root: the relevant one for this question is "resources".
In previous versions, IDEA only supported marking directories as "sources" or "tests".
So the new correct answer is to mark src/main/resources directory as a resources folder of your content root. By marking the contents of a directory as "resources", you're telling IDEA that the contents are not source code but need to be accessible on the classpath at runtime.
[Added as a separate answer because the first one is still potentially useful if your file is stuck under your source tree for whatever reason - feel free to merge it in to the other answer if that's more appropriate.]
I guess /src/main/resources is marked in IDEA as a source root? That's pretty much explicitly telling IDEA "the stuff under this directory is source files".
You could try adding the file to /Settings/Project Settings/Compiler/Excludes - but that will probably mean that your file won't get copied onto your output path (and thus won't be on the runtime classpath so logback won't see it).
My personal solution is that my logback.groovy sits outside of my /src tree - I consider it to be configuration rather than a source/resource file. My config directory itself is then added to the runtime classpath directly via /Project Structure/Modules//Dependencies (marked as runtime scope).
My solution was to modify the artifact to explicitly include logback.groovy in the WEB-INF/classes directory. It isn't ideal since this file could only be referenced by the absolute path and not as a project file, so any suggestions are still welcome.
I put logback.groovy in src/main/resources and added it to Resources patterns in IDEA's Compiler settings (ctrl + alt + s; Compiler > Resource patterns). And it works :)
Related
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 have a project with a GDSL file that describes a DSL delegate like:
def ctx = context pathRegexp: ".*installer\\.groovy", scope: scriptScope()
contributor(ctx) {
delegatesTo(findClass("com.whatever.InstallerBase"))
}
I package this file up in the jar (just in the root of the jar) using maven.
In a separate project I have a maven dependency on my jar artifact containing the gdsl. However, my autocompletion doesn't work. It works fine with the sample scripts in the first project (with the GDSL).
Is there a step that I'm missing in order for the GDSL to be picked up? Do I need to place it in a special folder in the jar?
The problem was indeed what #PeterGromov indicated in the comment on the question:
ensure that the library jar is only attached as classes and not library source as well
both the source and library were configured and thus IDEA doesn't include it. I have opened a youtrack issue to fix this here:
https://youtrack.jetbrains.com/issue/IDEA-137411
I downloaded the necessary pom.xml and jar files, now I need to organize them so Maven can find them, but I'm not exactly sure of the structure. Here's my guess:
For example, the maven-clean-plugin would sit here:
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.xml
I realize the best way to go about this would be download it on my computer and test it out, but I can't.
Also, would the same rule/methodology described in the path above be the same for any other xml and jar files?
I'm asking this because when I run "mvn clean verify -o" I get the error "The POM for org.apache.maven.plugins:maven-clean-plugin:jar:2.5 is missing, no dependency information available", even tho the POM is located in the path described above.
My solution to the problem above is simple, my solution to getting the build to work, is nearly impossible in my situation.
Change the extension of the xml file from
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.xml
to
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Once I did that I realized that each jar depends on other jars, which are described as dependencies in the pom file. And since each jar depends on each jar thereafter, etc., etc., it'd be nearly impossible to get each jar and pom, for me.
One thing I was going to mention is that you can command line push files into the .m2 local cache.
check the documentation here for more information: http://maven.apache.org/plugins/maven-install-plugin/usage.html
I currently switched from eclipse to android studio. In eclipse I had 2 projects, one android application project and one java project which I included in the android project as library. This java project uses ResourceBundles to create internationalized error messages for it's own errors. This has been my project structure:
/MyApp
/src
/res
...
/MyLibrary
/src
/res (added as source folder to build path)
/loc
Bundle_en.properties
This worked when loading the RessourceBundles as following:
ResourceBundle.getBundle("loc.Bundle", Locale.ENGLISH);
Now I switched to android studio and my new project structure looks like this (added the java library as module):
/MyProject
/MyApp
...
/MyLibrary
/src
/main
/java
...
/res
/loc
Bundle_en.properties
But I'm not able to load the ResourceBundles anymore, it's just throwing a java.util.MissingResourceException. I tried a lot of different locations for the ResourceBundles and different paths but I'm going to get crazy because nothing seems to work. Could anybody explain where to put those bundles and how to load them?
Thank you!
Faced exactly the same problem. To make it work I finally had to create a resorces folder in my project module's main folder.
here multiple files starting with the same name (as messages in this picture) gets bundled as a resource bundle.
Finally had to call it using
ResourceBundle.getBundle("org.eclipse.paho.client.mqttv3.internal.nls.logcat")
or
ResourceBundle.getBundle("org.eclipse.paho.client.mqttv3.internal.nls.messages")
to get the required resource.
If you include the second project as a library, you might not want to create a new resource folder as suggested in a previous answer (which does work). Instead, you can simply add the library's resource folder to your resource directories in your module's build.gradle: to the android section add
sourceSets {
main.resources.srcDirs += 'path/to/your/libs/res'
}
If now the added res folder contains org/mypackage/Bundle.properties you can refer to it using
ResourceBundle.getBundle("org.mypackage.Bundle")
Actually adding a new resource folder does nothing more then adding it as a resource directory in build.gradle.
I never tried but Intellij comes with very good integration of Resource Bundles.
Refer this link
http://www.jetbrains.com/idea/webhelp/resource-bundle.html
From the link above
Resource bundle is a set of properties files that have same base name
with different language-specific suffixes. A resource bundle contains
at least two properties files with similar base name, for example
file_en.properties and file_de.properties.
IntelliJ IDEA recognizes properties files, and if two or more
properties files with the names that differ only in suffix, are
encountered, joins them into a resource bundle. The new node Resource
Bundle '(base name)' appears in the Project Tool Window:
You can have these files inside your module or on root as well.
First please ensure your resource folder (where the property file is localted) is in the classpath and you can easily find that by calling the following.
URLClassLoader ldr = (URLClassLoader)ClassLoader.getSystemClassLoader();
URL[] urls = ldr.getURLs();
for(URL url : urls)
{
System.out.println(url.getPath());
}
Now if you find your resources folder in the classpath then you can simply call the bundle base name, in your case ResourceBundle.getBundle("Bundle"), no need for a fully qualified path. Assuming you are using English locale, it should find it. You can further add en_US, en_NZ, en_GB etc if needed.
If you do not find your property folder then make sure it is in the classpath and if you need to add it dynamically follow this thread.
How do you change the CLASSPATH within Java?
Remember the only addition for loading property files dynamically is that you MUST call findResource or findResources API on the class loader to load the property file. Hope this helps.
Working on the new android side of extensions with the changes. I have my separate extension as its own dependency.
In my code I require references to the Extension.Java class as well as the HaxeObject.
These are located in extensions-api, which is it's own separate dependency.
I've tried including these files in my own dependency, this causes top-level exceptions because a number of the Java files were included twice. I've also tried not including the extensions-api, this works to some extent, however If in the future I decide to use more extensions this won't work (less than ideal).
I need to find a way to reference these files from one dependency to another. so from: MyExtension.src.org.haxe.nme.MyExtension and extension-api.src.org.haxe.nme.Extension
So I guess the point I'm stuck at is how I make these two dependencies see each other whilst compiling so that when they merge to make the .dex file they don't cause top-level exceptions.
I could potentially hack it by placing my extension into the extension-api folder. Something like:
<dependency name="extension-api" path="dependencies/MyExtension" if="android"/>
The issue with this being that the androidManifest merging wouldn't work.
I found the answer here:
the gist is in the project.properties file you want to add the line:
android.library.reference.1=../extensions-api
http://www.openfl.org/community/general-discussion/native-extensions/