I've been trying to get On-Demand Resource to work but I keep getting this compile error:
/* com.apple.actool.errors */
: error: The tag combination "tagName" for "xxx.imageset/xxx#3x.png" has no output specification.
I had a look at actool man page and there's an option:
--asset-pack-output-specifications filename
Which says:
Tells actool where to write the information about ODR resources found
in the asset catalog. The emitted file will be a plist.
But I'm not really sure what to put as an argument/where this plist is used or even if this option is in the right track of fixing the error.
My coworkers and I struggled with this error for over a day and were only able to fix it by wiping our existing local repos and installing a fresh clone from our remote repos with the code that contains the on-demand resources.
In our case, I was the one that created the on-demand resources functionality and did the tagging for the assets. I built and ran all of that code, and everything worked fine locally on my machine. I pushed those commits to our remote, and when my coworkers pulled they received the asset catalog compile error that you reported when they tried to build.
I compared my build logs with those of my coworkers and found that I had the --asset-pack-output-specifications flag along with a filename whereas they did not, even though all of our production code was the same. I never set that flag manually myself during development, it was automatically generated at some point in the process but I have no idea where -- I didn't even know it existed until this build failure occurred. After struggling for many hours we noticed that if my coworkers deleted their local projects entirely and basically started fresh by installing a new project and repo again from the remote, they suddenly were able to build. They had already tried to clean and nuke their derived data, but that didn't work. Only totally deleting the repos and the projects entirely did the trick. Not sure why, but something about wiping the project and all associated directories and building themselves totally fresh from their own local machines triggered something that enabled the --asset-pack-output-specifications flag.
I just faced this issue and was totally against deleting my repo and cloning again.
I noticed that alongside this error, I also got a warning stating that I had assets under the same name (thus being duplicated).
Deleting the duplicated asset in order to get rid of the warning, fixed the compilation error.
Hope this helps someone, as deleting the repo and cloning again shouldn't be an option.
I just faced the issue.
I could solve it just by deleting on-demand resource tags and tagging them back again.
I just solve it by rebooting Xcode then run successfully. The error seems to only appear once...I don't know why.
I have been struggling with a very weird issue that has suddenly popped up on the latest version of Eclipse Classic (4.2.2).
Everytime I try creating or refactoring a class or subclass in any of my projects (all Java) in my Eclipse workspace I get an error at the very top of my class that says
A class file was not written. The project may be inconsistent, if so try refreshing this project and building it
Again, this happens when I create new classes. And even when I rename current classes, then undo the renaming, its totally fine, but changing a single character in the name causes this error to happen for that specific class.
I have Auto Build on, and I tried multiple times to clean and refresh every project as well as restart Eclipse entirely.
I have literally no idea how to even start figuring out how to fix this. The solutions i've found through search didn't help, so i'm hoping I might find any clues here.
I had the same problem and here's how I solved it in the end:
It turned out that the disc space on the drive where workspace resides was full.
Silly mistake but worth checking.
In my case, this was caused by the fact that the build output directories were owned by a different user, and Eclipse could not write into them.
I had the same issues, the following worked for me:
Right click eclipse then running "as an Administrator"
Click Project > Clean.
Clean your workspace by starting eclipse from the command line with the -clean argument :
eclipse -clean
See also How to run eclipse in clean mode? and what happens if we do so?
I solved this problem by running Eclipse as root.
I had the same issue on Mac OS X. I had a maven project.
Try running the following command on Terminal. This looks like an access issue.
sudo mvn clean
Provide password for admin user.
Then open Eclipse and refresh your project.
We are using Eclipse here too and have to handle a workspace with more than 200 plug-ins. Every now and then people have similar problems with their workspace and inconsistencies reported in a weird way by Eclipse.
What people here usually do is (next step only in case previous step didn't help):
- trying to ContextMenu->Team->Clean/Refresh the whole workspace
- creating a new workspace and check out all necessary files from the repository
- reinstalling Eclipse to a new directory
From my experience after using the Eclipse IDE on a daily basis for many years, it doesn't make very much sense to waste too much time with these issues, unless they aren't solved by one of the steps above. It takes too much time to struggle with these things, while starting from scratch is done in an hour or less (and usually fixes the issue).
If your Eclipse still behaves strangely it might make sense to go through your installed plug-ins. Not all external plug-ins follow the Eclipse guidelines and can seriously harm the performance and operational consistency of your Eclipse installation (E.g. Sonar Plug-in, Toad Plug-in, ...)
In my case this kind of error caused due to disk space got full and it got resolved by just freeing disk space where eclipse have been installed.
That is c/d/e drivers.
I come up with the same error, and in my case, this is because the permission of the project/bin directory is not recursively 775
I fixed it by:
Remove the project/bin directory: sudo rm -rf project/bin
Switch to Eclipse, rebuild the project: Project->Clean...
Then no errors.
Try to launch Eclipse as Administrator.
In my case such error was caused by a question mark in a quoted method name (I use geb+spock combination for automated testing).
So this method name will throw an error "Do you want something?"()
And this will not "Do you want something"()
It may not be the best response but to fix it, I've just delete the error marker.
Had the same issue. but cleaning the project and restart eclipse didn't help and disk space was not the issue. Solved the issue by copy the code to notepad(just to not lose it) and then delete the class, recreate it and paste the code back in again.
I solved it changed the owner of the project files. I changed from root(old owner) to user my current(user that i use with eclipse).
Just changed and saved java file to recompile the class. Then error disappeared.
I was try run
Project->Clean...
And Rebuild. My problem was resolved
For linux (Debia) and working on Spring boot project (maven):
$ sudo mvn clean
Then open Eclipse and File -> Refresh.
I had same issue, it is something similar but this post didn't help in my case. I have many inner classes which is causing the compiler to create class names with all inner class names together that is creating class name more than 255 character file limit on NTFS! read it in some other blog. I thought it will be helpful to post here.
Ex : classA$InnerClassB$......InncerClassZ.class in target folder it won't generate the class if it exceeds this limit. Try renaming your inner class name shortened. In my case i have to add InnerclassZ as its exceeding its not generating class and Eclipse complaining.
A class file was not written. The project may be inconsistent, if so try refreshing....
I shortened InnerClassZ to IClassZ fixed the issue.
I had the same issue and it got fixed by running eclipse in administrator mode
Eclipse Shortcut-->Right click-->More-->Run as Administrator
I've been throught that error once when I used wsdl2java to extract java classes from a wsdl, it turns out that all classes were created in the same "class", causing end classes with long names (error - File name too long). When I organized and rename some classes the error disappeared.
I had this issue. I did the following, it resolved.
Open Eclipse in Administrator mode; Right click on eclipse.exe "Run as administrator"
Clean all projects.
#Denny's answer put me on the right track, though in my case it was the target directory. I deleted it for some reason and something automatically recreated with owner root. Changing the directory owner was not enough as it contained files that were also owned by root. So make sure to really remove the complete content of the directory and to change the owner.
In my case current user didn't have access to this project dir
Before giving a try to the above solutions. Just cleaned the project and it worked.
I recently switched my development workstation from Windows to Linux (Fedora64). I use Eclipse with PDT and CVS for PHP programming. I copied my entire project folder, including the .project file to my Linux system and imported it in Eclipse. It automatically detected the CVS server IP and login. However, when I sync, it shows all my files (>8000) as outgoing, and moreover the sync is always stuck at 79%. How do I fix this without checking out the entire project from CVS again? Thanks.
This might be an issue with timestamps that are now slightly out-of-sync with the meta data recorded in the hidden ./CVS folders of your working copy. Try running cvs status on your sandbox (sorry, I'm not familiar with Eclipse's CVS interface, but that's how you would do it on the command line). That should reset the supposedly modified files.
You also might get away with simply running Update. If all else fails, do a fresh Checkout.
Update: I googled a little and found some articles that can be interpreted to say that Eclipse does an implicit status when doing an "Update" or "Update Check".
I get this error in realtion to my [username].mode1v3 package file:
Error: 155015 (A conflict in the
working copy obstructs the current
operation) Description: Commit failed
(details follow):
I can do a compare from the SCM results menu on this file. Doing so reveals 102 conflicts (differences) between my local copy and the latest version in the repository. Problem is I don't understand what this file relates to or how to fix it. Differences occur in the file under keys like
PBXSmartGroupTreeModuleColumnWidthsKey
which I have no idea about.
I am the only one working on this project. How is it possible to resolve a conflict such as this?
Many thanks.
Sounds like you're probably working on two computers?
Any conflicts that happen in that file can safely be ignored - just tell your SCM to accept your local version. It's one of the files Xcode uses to keep track of your project state within the IDE.
I'd recommend taking it out of source control and telling your SCM system to ignore it.
This file contains your personal Xcode settings (like window positions and so on). It should not be under version control at all.
After doing a fresh checkout using Subversive, some of the directories retrieved because of svn:external properties are showing up as obstructed. However not all of them are. A command-line use of "svn status" properly shows all the directories as externals with no obstructions.
Why is this happening?
This does looks like this thread
We checked the situation and we had found that the problem can happen in case if working copy is locked by external process in time of update.
For example, the process TSVNCache that related to TortoiseSVN time-to-time produces conflicts with working copy access and JavaSVN library cannot complete working copy modification in correct way. As result working copy goes into "Obstructed" state, i.e. it is damaged.
The same diagnosis related to any process which locks working copy in time of working copy meta-data modification. (We found same behavior for MS Visual Studio 2005 Express Edition, but I don't know why the Studio locks WC?)
So be sure to make the checkout with the least possible number of application running.
Another source of conflict could be:
The SVN 1.4.x-compatible clients are automatically converts working copy into 1.4.x-compatible format. At the current moment Subversive Default client is incompatible with SVN 1.4.x working copy format.
So, if you performed any modification of the working copy using command line SVN client in your case you will get "Obstructed" state indicated over the resources in the workspace tree.
In order to resolve the problem I will propose you to switch SVN client option and select SVN Kit 1.1.0-based client or Native JavaHL 1.4.2 client.
Next, if resources already decorated as "Obstructed", please close and then open again corresponding projects or simply restart Eclipse IDE in order to reload SVN meta-information cache.
Now : the exact version may not be the same for you, but that is another lead to check.