Random .r files created when using Jenkins and SVN - android

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.

Related

Why can't I hit the breakpoint when I start debug the Xamarin Android Application?

When I start to debug my first Xamarin Android application, I set some breakpoints. Whatever I do, it will still not hit the breakpoint. What's wrong with this?
I have tried many times, but it did not help.
I've found that the name of the folder that contains your project can make a difference. Do you have any spaces or punctuation characters in yours?
The folder name is often the same as the project name, but it doesn't have to be. I had a Xamarin Android project called "Engagement (Android)" within a solution, and by default it was stored on disk at ...\Engagement (Android)\Engagement (Android).csproj
No matter what I did, it wouldn't hit breakpoints. Brand new projects that I added (called Test1, Test2, etc) - debugged perfectly.
When I changed the folder name to "Engagement_Android" (keeping the same project name) - it started hitting breakpoints again.
Other symptoms that went with this included the "Clean Project" option not clearing all the files from the bin/debug folder (it left behind the project's main DLL and PDB file).
The thing that nailed it for me was noticing that when I did a clean build, the bin/debug folder did not contain an "MDB" file for the main exe (in this case Engagement Android.dll.mdb) and so was not been packaged into APK file.
It turns out that the MDB files are the way that debugging information gets packaged up into the APK - without it you can't debug! I think they are created by a tool called PDB2MDB.exe during the build process.
If you try this, bear in mind it is the physical folder name not the project name that is important. Also, you need to edit the SLN file because it contains a reference to the path of each project in the solution - so make the change there too.
I experienced the same issue before and, I've managed to find a workaround for this. I have tried cleaning all of my project’s bin\Debug folders manually and this worked. Just never rely on the clean solution/project alone because this doesn't delete all the files in your output folders. After, rebuild your projects.
Also, try save all your work and shut down Xamarin Studio and restart it.
I have had a few issues in the past that only disappeared when I restarted the IDE.

CreateProcess error=206, The filename, or extension is too long

CreateProcess error=206, The filename or extension is too long - Android Studio
What does this error mean and how can I solve it?
I tried Android-Studio in committing projects and Tortoise SVN, seems like tortoise-svn does the job unlike android-studio's plugin which is SVN. I dont really understand why, but Tortoise-svn is working so I think this could be an answer.
Make long story short: The temporary-fix is using Tortoise Svn rather than using Android-Studio's SVN.
Windows has a max path length of 260 characters. See max path length of 260 characters. See Android Studio - Unable to open PNG file
According to another thread the "svn cmd absolute path" works, but the relative one "cd /your/project/path;svn cmd yourproject" doesn´t (It´s a Windows File System "Problem")
Android Studio seem to work with relative paths, Tortoise with absolute. The error message also says
cannot run program ( IN directory .../.../yourproject)
Which confirms this assumption.
Hopefully they will change it in future!!
I had the same problem and installing Tortoise SVN didn't solve it. I proceeded to commit individual directories in my project step by step, trying to find the file/directory that was causing the problem. My surprise was when I finished all commits and no error had arised.
So the solution for my problem was to commit all my files/directories step by step.
I know the thread is a bit old but here is a a work around for googlers ,
Android Studio gives you the exact address of the folder which can not be committed:
Error:Cannot run program "svn" (in directory "c:\blah-blah"): CreateProcess error=206, The filename or extension is too long
Unless AS or Microsoft does something for supporting file names longer than the current limitation, here is a couple of workarounds to pass this :
1- to commit the given folder c:\blah-blah using another svn client eg. TortoiseSVN
2- to move your project folder closer to the root of the drive, for example if your project is in d:\Development\Android Studio\sources\project x\Version 3\... try to move it closer to the root, by removing and/or renaming in between folders like: d:\dev\as\src\x\v3\... or d:\x\v3\...
3- I read somewhere that creating a virtual drive in windows from the last folder would work too, for example, create a z:\ and assign it to d:\Development\Android Studio\sources\project x\Version 3\ but I read somewhere else that this might not work cause the AS svn client work with absolute path of files, any way I made the job done with options 1 and 2 and never got to try the third option
The error is often produced when too many files are commited at once and the command line client is used; as the files are delivered to the client in one line, the line becomes too long (svn commit file1 file2 ...). See also SVN commit fails when committing lots of files in one commit (resulting svn command length exceed the limit). My solution to this problem was to uncheck "Use command line client" in the settings under "Version Control - Subversion".

archive for required library could not be read or is not a valid ZIP file

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

Eclipse 'Project > Clean...' removes my additional Android src folder. How to fix?

In my Android project I've created an additional source-code folder called src-plugins. I added it to build.properties and building the project works fine.
However, now and then my gen folder won't regenerate and the solution is always to do an Eclipse Project > Clean.... However, this also removes the deepest sub-folder of src-plugins -- including all of its files.
Question: Is there a way to fix this?
I'll preemptively answer the most likely comment: I'm not using a subpackage because I need access to package-private class members. But I still feel I need to group these files in a separate folder.
Without any logs or the layout files, activity files etc. it's even different to be reproduced, but this might be related to the same old R.java problem, when you have problems in some of the layout files. You said that it's sporadic, but you must trace what has been modified during the normal behaviour and the dissapearing of the folder. This might just be something really small and simple as that.
select Build > Clean Project in your IDE or alternatively use ./gradlew clean from the console.

Eclipse: How to ignore .git subdir when adding one project to another project's build path?

I'm developing an application that is supposed to run on both Android as well as regular Java SE.
I have an eclipse project called foobar-core which contains code that is used both by the Android and the SE version. I have another project called foobar-android, which contains all android-specific code.
I need to reference some of the foobar-core code in the foobar-android project, so I added foobar-core to foobar-android in Settings -> Java Build path -> Projects -> Required projects on the build path. This works fine, as I can use code from foobare-core in foobar-android now.
Here's the problem: Both foobar-core and foobar-android are independent git repositories, which means they both have a .git subdirectory. Now I get a lot of warnings on the "Console" tab whenever I compile foobar-android. They look like this:
/foobar-core/src/.git/HEAD conflicts with another file already put at .git/HEAD
/foobar-core/src/.git/config conflicts with another file already put at .git/config
/foobar-core/src/.git/description conflicts with another file already put at > .git/description
/foobar-core/src/.git/hooks/applypatch-msg.sample conflicts with another file already > put at .git/hooks/applypatch-msg.sample
How can I tell Eclipse to ignore the .git files when importing sources from the foobar-core project?
Even if you just have a single git repo, it is good to ignore the .git directory because other Eclipse will waste a lot of time looking at the files in it even though it never needs to do anything with them. In particular, when you do a project wide search, Eclipse will search through the all the files in .git directory, which takes a long time and ends up showing you lots of duplicates (or almost duplicates, older versions of the same file with the same search term found).
I think the Eclipse git extensions probably take care of this but if you don't want to install yet another extension, the best way I have found it to tell Eclipse that all .git directories are "Derived", which seems to make Eclipse somewhat ignore the contained files.
You do this by switching from the Package Explorer view to the Navigator view, where you should see the .git folder. Right-click on the .git folder, selecting properties, selecting Resource from the settings selector, and then checking the "Derived" box.
I would setup a .gitignore file that simply ignored the entire foobar-code project.

Categories

Resources