I have a Kotlin-based Android Studio project located at C:\DEV\PROJECT1 which works fine. I copied the project SOURCE to C:\DEV\PROJECT2 and loaded it into Android Studio.
All of my classes as well as my namespace have a red underline under their names in the Project panel to the left and each editor tab. The IDE thinks there are duplicate classes because it's still referencing the source code in the OLD directory.
When I debug, the IDE says there are multiple versions of a class and at the top of the editor window you can choose from either directory.
This is causing a huge problem for me for multiple reasons, so I'd like to get the IDE to forget about the old directory when loading the new copy of the project.
I've tried all the tricks I found on the Internet but none of them work. I've manually deleted the "caches" directory in C:\Users\me\AppData\Local\Google... I've done the same thing within the IDE with File->Invalidate Caches. I've manually deleted the .gradle and .idea directories, as well as all build directories.
I had a friend load the project SOURCE on his computer the same as I've done above, and he experiences the same issue. So I don't believe it's an environment issue.
Does anyone know what's going on here and how to fix it?
Thanks.
None of the other answers mentioned worked for me. What I had to do was change the value of 'rootProject.name' in settings.gradle. Until I did this, it would always remember the old directory where the project used to be and would always use source from that directory.
This makes no sense to me so I'm going bo post another question to see if someone can explain why Android Studio NEVER forgets the location of a project name. I can't imagine anyone ever wanting that behavior.
I started cloning an Android project from my Git server and while initially opening the project Android Studio gave me an error: "Cannot load module myProject" and asks me to remove it.
After the removal Git then is already showing me a change made to the modules.xml file:
<module fileurl="file://$PROJECT_DIR$/old_project_name.iml" filepath="$PROJECT_DIR$/old_project_name.iml" />
got changed to
<module fileurl="file://$PROJECT_DIR$/new_project_name.iml" filepath="$PROJECT_DIR$/new_project_name.iml" />
That's caused by the different project name (Android Studio / IntelliJ can't find the path listed in modules.xml) and is therefore hard to put under version control where users may have different names for their local clone of the project.
There already is a post about making this project name user-independent, coming to no results.
The IntelliJ IDEA help site states:
The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.
Almost all of the files contain information core to the project itself, such as names and locations of its component modules, compiler settings, etc. Thus, these files may (and should) be kept under version control.
Another answer on a question about version control for the .idea/ directory is about configuring Gradle / Maven to substitute the IDEA project files.
How is this done?
Is there a way to achieve a user-independent modules.xml?
EDIT: Adding the file to .gitignore appears to work, the IDE will generate it.
I'm migrating my Android project from Eclipse to Android Studio. I use Subversion and am wondering how I can migrate my SVN to the new file structure used in Android Studio without losing my history.
Thanks for any help!
Posting this because it might help someone else.
I ran into the same problem as well. #user714965 was inspiring but didn't solve my problem because I couldn't figure out how to get SVN recognize that I moved a file from the original folder to the new structure in my working copy.
For the following, you will need TortoiseSVN or a similar SVN GUI client to do this.
Here is what I did:
Commit the Eclipse project last changes into the SVN repo.
Open Android Studio and use that to import the Eclipse project working copy.
Android Studio will nicely convert the Eclipse project into a Android Studio/Gradle project. Let's call this project "PrjGradle".
Open the converted Gradle project folder window and keep it one side of your screen
Go into your SVN repo where you have your project (using TortoiseSVN).
Backup your current trunk into a branch or a tag and call it "final_eclipse" or whatever.
Now, mirror the folder structure of the newly converted Gradle project on your local machine directly on the TortoiseSVN Repo Browser window. Meaning, look at how the directory is structured in "PrkGradle" and create/delete/rename folders directly on the trunk repository. This will be painstakingly tedious but you have to bear with it if you want to preserve your SVN history.
When you move files around (not copy) directly on the repo, the history of the files remain intact.
Once you complete, check out the restructured directory into your local machine. Let's call this "NewPrj".
Use a suitable Folder compare program (such as Beyond Compare) to synchronize missing items (such as build.gradle, .iml files, etc.)
Rename your converted project to "PrjGradle_old", and rename the newly checked out project (NewPrj) to "PrjGradle".
Open "PrjGradle" in Android Studio. That's it!
Hope it works out.
I don't know the differences of both file structures. But it would try it this way:
Check out your project (maybe better use a client like TortoiseSVN)
Build the new file structure (new folders)
Commit
Move the files from the old structure to the new
Commit (check the commit dialog if there are move actions only!)
Delete old folders which you don't need anymore
Commit
SVN will recognize these move operations. You will see if it works by the operations in the commit dialog. If there are "delete"/"new" actions something went wrong there should only be "move" actions.
Before coming to the problem let me explain what I did that has landed me in the problem.
I created an account on github and made a repository named Android.
Then I installed github client in my windows 7.
Then I opened this client, provided my authentication and cloned the repository to a local directory C:\Users\Aniket\Documents\GitHub\Android(This folder has the .git folder in it).
Then I went to my Eclipse ADT and installed EGit plugin as described here. Also I
Then in Eclipse I right click on my project TicTacToe go to Team->Share Project and provide my repository path i.e C:\Users\Aniket\Documents\GitHub\Android.
My Project was added to the local repository and in my github client it shows me all option to commit file in the actual repository on the github site.
But my project is suddenly showing error with a red '!' sign on it.
Description --> Archive for required library: 'C:/Users/Aniket/AndroidWorkspace/TicTacToe
/libs/android-support-v4.jar' in project 'TicTacToe' cannot be read or is not a valid ZIP file
Resource --> TicTacToe
Path Location --> Build path
Type --> Build Path Problem
Note : the Error was a single line displayed in error console on Eclipse. I just split it up for readability.
Even after detaching repository it shows that error.
Has anyone encountered this scenario before. What is the solution or workaround? I googled and first few links suggest it is an Eclipse bug. Please suggest what can be done to bring my project back to executable state?
It is an Eclipse bug. I have faced the similar problem several times. closing and reopening the project works sometime. if it doesn't work try restarting Eclipse.
I've seen the same issue. I removed that jar file, and then rightclick on the project, select maven, and do "update project...". The jar was downloaded again, and the problem was gone.
There is other case to display error Archive for required library
Right click on project and open --> project project properties --> java build path --> Android private libs
if there are two jar files with same name then remove one from libs.
jar file may the hidden some times then
open you libs folder in window and check if any hidden files are exist
Organize --> folders and search options --> view --> check show hidden files
and Delete the hidden jar file , The same cass delete if hidden java fies exist in src and packages if any
Looks like everyone has different story to tell! For me, I had to delete the error from eclipse Markers tab, and then cleaned the project again. Before that, I closed and re-opened the project/eclipse several times as suggested by #rachit, which did not work for me.
In my case, i'd downloaded project from internet, after unzipping project some files had been blocked, just unblock files and try again, then problem was solved.
In my case I tried all the tips suggested but the error remained. I solved changing version with a more recent one and writing that in the pom.xml. After this everything is now ok.
In my case restarting Eclipse did not solve the problem. I restarted the computer and did a Project -> Clean in eclipse
A solution that worked for me:
go to *.classpath and delete the line :
<classpathentry kind="lib" path="the_problematic_class.java"/>
Could be due to corrupted jar files as well. Better to check that first as that was the reason in my case:
jar tf myjar.jar
should list the content inside.
i was facing same problem in Eclipse Mars. I downloaded the jars from [https://oss.jfrog.org/webapp/#/artifacts/browse/tree/General/repo/org/ethereum/ethereumj-core/1.0.0-SNAPSHOT][1]
and replaced it in the directory.
I got error while adding ethereum.jar using pom.xml at C:\Users{machineName}.m2\repository\org\ethereum\ethereumj-core\1.0.0-SNAPSHOT\ethereum-core-1.0.0-SNAPSHOT.jar , i added the downloaded jar(ethereum-core-1.0.0-SNAPSHOT.jar) here and the problem was solved.
I will say that it can be that some answers work for some cases, but for me it was necessary to go an extra mile. So I will try to make a summary of what can be done:
Verify that the jars are intact:
jar tf myjar.jar
Restart eclipse and update projects setting over right click on project -> Maven -> Update project
The option which has work for me was to navigate in the workspace folder and then delete the files:
.metadata/.plugins/org.eclipse.jdt.core/invalidArchivesCache
.metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache
After that restart eclipse and rebuild project.
I found no duplicates anywhere and tried restarting eclipse, rebuild project. I was getting error for only one libary. So I just tried to rename the jar file from ksoap2-android-assembly-2.5.8-jar-with-dependencies.jar to ksoap2-2.5.8.jar
So if none of the problems solves from above you can also try this one
In my case, the java installation was not proper. So, I uninstalled Java and reinstalled a new version. Now, it works.
For us, the problem seemed to be the size of the .jar file. I would recommend doing the following test to see whether this is the case or at least rule it out. First have a look at other jars in your Eclipse project and compare them to the problemetic jar. Is it a lot bigger than the others? If so, try the following workaround. Else, this answer probably won't help you. Before starting, configure Windows to treat .jar files as .zip files with the following command line command:
assoc .jar=CompressedFolder (see https://superuser.com/questions/121540/can-you-configure-windows-to-open-jar-files-like-zip-files-without-a-3rd-party-t)
Optional: A simple Test
Before trying the workaround, here is a test to see if it is indeed the jar file size that's tripping you up.
Create a large .jar full of random .class files that aren't in your problematic jar. You can do this by making a folder full of files, zipping it, and renaming the .zip extension to a .jar. Windows might warn you about changing the extension. Ignore this. Make sure you have enough files in the folder so that it's a bit larger than the problematic jar.
Try to import this artificially created jar. If it fails with the same error, then size is probably the issue.
The Workaround
If it is indeed size that's the problem, which you might have identified by doing the optional simple test above, you can try the following workaround.
Decompress your .jar file. You should be able to do this easily in Windows
Split the folder you get from step 1 into smaller sub-folders. It could be just two folders, or more, depending on how big the original is. You want the folders to be smaller than some of your existing "good" jars so that size won't be an issue. Make sure to keep the package structure intact when you're doing this.
Zip up all the folders you created in step 2, and rename the .zip to .jar.
Import all of the .jars from step 3 individually.
The steps might be a bit unclear, so here's an example. Imagine your jar file was called mylib.jar. You unzip this to a folder called mylib. Inside, let's say there are three sub-folders called package1, package2 and package3. Create 3 folders called mylib1, mylib2 and mylib3, and put in package1, package2 and package3 respectively. Then zip these up and rename extension to .jar. You'll then be importing mylib1.jar, mylib2.jar and mylib3.jar.
For Java web application, web.xml added as jar in the project. In project explorer, try to find web.xml as in jar icon and remove from the project. Error will go away!!
I was stacked on this problem for days despite searching for a solution on the net. I first moved my project to Netbeans and all worked fine. I then returned to eclipse->properties->java compile-> Building and changed "Incompartible build path" option from error to warning and then did maven update and it worked.
I realize this is an old question, but I have yet another solution if none of these work for other people coming across this thread.
I had this same problem, and spent alot of time trying to figure it out, only to find that my Eclipse classpath/buildpath has a .json file in it, it doesn't like that, so it wouldn't compile.
So, check to make sure no text files or json files, etc are in your build path.
I had accidentally put the web.xml into the build path :x
I've got an automated build system from my Android project using Jenkins which syncs via SVN.
Occasionally I get new files added to the workspace which I assume are from the SVN process that are collisions. When this happens in the resource folder it causes a build failure as the file extensions are stripped and there is a name space collision.
e.g.
[aapt] res\drawable\icon.png.r584:0: error: Resource entry icon is already defined.
[aapt] res\drawable\icon.png:0: Originally defined here.
[aapt] res\drawable\icon.png.r588:0: error: Resource entry icon is already defined.
[aapt] res\drawable\icon.png:0: Originally defined here.
Any ideas why I'm getting these r584, r588 files? Probably more importantly, how do I stop this from happening?
Whilst the jenkins build is local to the machine, the original SVN directory I work in is inside a dropbox managed folder (don't ask!). Whilst I don't think this is a problem I feel I should mention it just in case it does have a contributing factor.
These .r??? files don't exist in my original source tree or SVN structure so can only be made by the SVN syncing operation done by Jenkins as far as I can see.
they look like conflict markers - when you merge, if it cannot automatically resolve the issue, it will put 2 temp files in the directory with the revision numbers as part of the file extension. You're supposed to use a diff app to decide what the final file should look like and then tell svn you've resolved the conflict. SVN will then delete the old temp files and let you commit your change.
Your commits will have garbage in them today - if you look at the file of the same name, you'll see diff markers embedded in the source. I'm surprised you can commit at all, but I guess the dropbox copy is somehow affecting the situation - are you committing deltas or just checking in the directory as if it was a bunch of new files?
Like others have said, *.rNNN are SVN merge conflicts, where NNN is the revision number that is in conflict. Again, like others have said, Jenkins must be the owner of the workspace, not something else.
Let me just try to clarify something here. You said "the original SVN directory I work in is inside a dropbox managed folder (don't ask!).". Are you saying that:
a) You are using a custom workspace for Jenkins (you would have had to muck around with custom workspace settings for that)
b) Your (user's) working directory is a dropbox managed folder
If b) is true, that's OK. But if a) is true, this may cause all sorts of problems. If this is the case, you really need to let Jenkins manage its own workspace. Yes, that may mean double the space-requirements, but this is the way it should be.
Now, assuming that Jenkins's workspace is managed by Jenkins, the first thing it will try to do is SVN Update. This should never cause merge problems (those *.rNNN files), unless something is modifying the workspace. Again, if point a) is true, consider giving Jenkins it's own workspace. The build itself could be modifying the workspace (I am not familiar with Android builds or what it does with files).
In either case, what you want is to do a clean SVN checkout. There are two options that will work for you.
Always check out a fresh copy
Use svn update is much as possible with 'svn revert' before update
Both of these are found in the job configuration, under "Source Code Management", under "Check-out Strategy".
The first will clean the Jenkins workspace and do a full checkout. This may be longer, but "cleaner".
The second will try to revert any local changes to the workspace before doing an SVN update, thus eliminating the merge conflicts.
AFAIK, the *.r### files are, like you suggest, when there is a conflict with what is being checked out. (I tried to find a good reference and didn't. I have seen them myself though.)
Since these usually happen when there is a conflict upon checkout, there are a couple of things I would look at for solving the issue.
Make sure that the files being checked out in your Jenkins workspace are not being modified. If they are supposed to be modified by the process, you might want to look at this answer to Force SVN checkout to overwrite.
Check the permissions of the directory vs. that of the user Jenkins is running under.
In general, Jenkins should be the owner and only manipulator of the workspace for any jobs it is running.