I have a project and I've found that the content in search path has many backslash at the beginning and the end of the correct search path.
It it like
\\\\\\\\\\\\\\"$(SRCROOT)/MY-SEARCH-PATH"\\\\\\\\\\\\\\\
So is it a bug or something I did wrong?
It looks like you're using some kind of tool (like Cocoa Pods or similar) on your project that modifies the project file. This tool might have a buggy way of interpreting build settings and saving them again.
No idea, however it's wrong and should be changed back to:
$(SRCROOT)/MY-SEARCH-PATH
(i.e. no backslashes and no double-quotes)
Related
So I'm trying to compress some documents I made when I get the following error message:
I have no idea what the character is, as it just looks like a blank space. I have removed the blank spaces from my documents and it still won't let me zip it. Online answers seem to refer to needing the change the language setting on my computer, but I haven't written any foreign languages. Any help would be appreciated.
Go to Users directory and make a new directory called 'Analytics',
Then, move you 'Account_Over_Time_Analysis' to this folder and try to comporess again.
If it fails again, please try 7zip incase your using something else.
Such an error could be caused from different language dir-name, a name with spaces or a name with escape chars.
To fix this you could hunt around for the correct language pack, or just install 7-Zip and use that to zip the files instead
There have been some questions about this, but none of them solves my problem.
I use SonarQube to do code analysis on one of my projects, which contain a Migrations directory. I would like to exclude all the source files in that directory from the code analysis.
In the projects Configuration->Settings->Exclusions->Files->Source Files Exclusions I added "**/Migrations/.", but in the analysis results I still get issues in code files in that directory.
The directory structure of my project looks like this: \MyProject\Migrations\SourceFile.cs
What am I doing wrong? Am I entering the wildcard in the wrong place, or my wildcard is wrong?
In the logs I can see
13:06:23.460 INFO - Copy-paste detection exclusions:
13:06:23.476 **/Migrations/*.*
but then I can also see
13:06:12.076 INFO - Inspecting <MyProject>\Migrations\SourceFile.cs
That's the correct place to set it up. Please try simply /Migrations/** or /MyProject/Migrations/**. When you go to one of the issues you want to get rid of, you'll see what your "regex" path should start with.
And one more tip: To see result, you have to rebuild the project, run sonar again. And again, until you get it right.
I had to use a different setting.
Instead of Configuration->Settings->Exclusions->Files->Source Files Exclusions I had to use Configuration->Settings->Exclusions->Issues->Ignore Issues on Multiple Criteria.
In this setting, I had to set the RULE KEY PATTERN to *, and I had to set the path wildcard in the FILE PATH PATTERN, **/Migrations/. works perfectly.
I'm using Maven to generate an archetype. I'm able to get the archetype to generate fine and the project template it generates works as expected. The only problem is in my shell scripts. Anything commented out in the script gets stripped leaving behind only commands. I've searched high and low and all I've been able to find was another user facing a similar issue with java comments. https://stackoverflow.com/questions/18797333/maven-archetype-generation-is-stripping-java-comments That question remains unanswered, so I figure I'll ask again. Does anyone know why Maven archetypes strip comments or how to prevent this from happening?
Using the #set command itself to set a #hash variable equal to "#" worked, allowing me to maintain shell comments in scripts generated by the archetype. This can get relatively ugly when using 80 # symbols in a row in a header, but that's another matter...
I also had a similar problem with hashes. On page http://johnjianfang.blogspot.com/2009/03/escape-properties-in-maven-archetypes.html I found answer.
Something like this works fine in my case:
#set($hash = '#')
${hash}
Output:
#
Maven uses Apache Velocity to perform substitutions/replacements when copying your archetype's template files to the project locations. The '#' character is used to begin directives, e.g. #set, in Velocity. My guess is that Velocity doesn't recognize your comment as a valid directive and silently deletes it during the replacement process.
Though I haven't verified this works - I would try escaping the comments with using a backslash (\) as defined in Velocity's user manual to solve the issue.
I've created a project and built out a several model classes. I've decided that I'd like to recycle them as a separate framework. In doing so, I want to change my class prefix of those files. The issue is, of course, that I now have to batch rename my files and my classes. I could use the refactor tool, but I have tens of classes, so it would be tedious. Is there a good way to automate the process? For reference, I'm using Xcode 5.
For anyone looking for an answer, I think I have a solution, although it's something I'd like to see built in to Xcode. I've filed a radar.(#15261680)
I had three things to worry about here:
The class names themselves. The class prefixes didn't match the framework that I wanted to put them in.
The file names. Even if I did a careful global search and replace and changed the class prefixes, the file names would be wrong.
The Xcode project references. Xcode keeps a list of your files, and I had to be sure that Xcode would know where to find my files, in the event that I renamed them.
What I did:
I did a global search and replace. Instead of clicking "Replace All", I used the "Review" pane, so I was able to exclude about ten or so cases that I wanted to keep with the original prefix.
I found a utility to do a batch rename. Now my files and classes all match nicely.
Uh oh! Xcode doesn't know where my files are, now. To fix this, I opened the .pbxproj file and did another careful search and replace. (I made sure to quit Xcode first, so my changes wouldn't be overwritten automatically.)
This was a bit of an involved process, and I was hoping that there was a tool or Xcode feature to help me do this, but alas, not yet.
I'm having trouble with Xcode 4.5.2's analyzer. It is able to find issues:
But, while the issues are displayed on the top bar:
,
the issues are not shown inside the file editor. Without this information, there is no practical way to know what the analyzer was talking about.
Is there a log file somewhere where I could find a line number for the detected issues? Any other workaround or setting tweak?
The only workaround I can think of is running the analyser from the command line. That can be done directly on Xcode projects (ie, no makefile barbarism required) and should give you direct textual feedback.