Using gradle-plugin 3.0.0
Gradle distribution 4.1.0
react-native 0.50
Linux fedora 27
app name is u1b.
Project structure
/proj/mob/rn.common (this is where node_modules is and all my js related stuff)
/proj/mob/a/u1b -- is where the android app is.
the project structure is different than the one normally created by boiler plate react-native create app script (because my node_modules is not just one level up from the android app).
But not clear if this is an issue or not.
I have been building my android with react-native library, in debug mode.
Now its time to start building release.
But I am running into a problem
bash gradlew assembleRelease errors out :
> Task :app:bundleReleaseJsAndAssets
Scanning folders for symlinks in /home/v/devel/mine/proj/mob/rn.common/node_modules (12ms)
Scanning folders for symlinks in /home/v/devel/mine/proj/mob/rn.common/node_modules (9ms)
Loading dependency graph, done.
warning: the transform cache was reset.
bundle: start
bundle: finish
bundle: Writing bundle output to: /home/v/tmp/u1b/app/intermediates/assets/release/index.android.bundle
bundle: Done writing bundle output
bundle: Copying 18 asset files
bundle: Done copying assets
/home/v/tmp/u1b/app/intermediates/res/merged/release/drawable-mdpi/src_jsapp_img_material_ic_local_library_black_48dp_android_drawablexxhlack_48dp.png: **error: Invalid filename. Unable to add.**
The image file it is looking at is, indeed not there. However I have no idea how that file name is constructed and, why it something is looking for it.
my gradle.properties contains a flag to switch to old apk due to a bug
# https://github.com/react-community/react-navigation/issues/1976
android.enableAapt2=false
could somebody shed a light on how the image names are decided and what might be causing the error
thank you
Resolved.
I figured out how the offending file name was constructed, and then I was able to mitigate what seemed to be 'too deep of a path for image file'.
Basically the file name below
src_jsapp_img_material_ic_local_library_black_48dp_android_drawablexxhblack_48dp.png
was concatenation of a path where the file resided in my javascript folder (starting from same level where node_modules are )
my index.android.js referes to a static icon file
icon: require('./src/js.app/img/material/ic_local_library_black_48dp/android/drawable-xxhdpi/ic_local_library_black_48dp.png'),
When the bundler constructed that offending file name, It was basically appending elements of the path to the file together, with some 'mangling'. Like removing a dot (so js.app became jsapp)
I just copied that file over to a higher level directory (to reduce the length of the release-constructed file name)
And then the release build started working.
The length of the offending file name was about 177 characters long. Not sure why it created problem for the release build. I suspect this is a limitation of android tools, not facebook's problem. I switched back and forth between buildTools 25.0.3 and 26.0.2 (that also meant switching android plugin versions .. .and that whole thing took quite a bit of time). But the problem was in either of the buildtools versions.
So I just figured deep directory structures for js static resource (eg images) is a problem for now. So better use smaller directory depths.
I am thinking of putting my folder with design files in my open source project but being afraid that they will be used within compiling for ios or android app.
Is there a way to exclude this folder?
Thank you in advance.
If it's an open source project, I think you should keep resources in your repo and add them to your projects .npmignore file. This way, when you get the module via npm install, the resource files won't even be in node_modules folder and users that use your open source project won't need to change anything in their config files.
OS X Version 10.10.5
Xcode version 7.2.1
Very simple steps, yet Xcode can't fathom what to do when you duplicate a folder that contains an Xcode project.
Start with Xcode CLOSED.
Start with an Xcode project that builds and runs perfectly.
Go to Finder window and right click on the directory that contains the buildable Xcode project and hit "Duplicate"
New directory is created, called "SomeProject copy"
Go into this new directory and double-click on the SomeProject.xcodeproj file to open it in Xcode.
Bam... enjoy your build errors.
In my case, it's complaining about an enum.
Tried deleting derived data folder (did so directly using finder)
Tried super-cleaning the build folder by holding down the option key.
Tried removing and re-adding complained about file that contains errors.
Tried changing path to file in Xcode File Inspector from "Relative To Group" to "Absolute Path"
I should also point out that either Finder -> Duplicate doesn't actually do what it says it does. Neither does Finder -> Copy, ~OR~ Xcode for some reason has now adopted not only the original source location as where to get its build files, but also the new location, hence the "Redefinition" error. I noticed that if I open the "copied" project and edit a file, then go back to my original project in an entirely different folder, the file is changed THERE.
And my paths (according to Xcode File Inspector), are RELATIVE TO THE PROJECT IN QUESTION. So in other words, ProjectAAA's files are pointed to the path under ProjectAAA's directory, and the same with copied project, ProjectBBB's files.
So somehow, the copy/duplicate is refusing to actually copy/duplicate.
Any ideas how to solve this?
Per John Elemans comment, moving my original project then revealed in the copied Xcode project a number of build paths and issues that needed resolving. I fixed those, and it worked as expected.
I solved this issue as follows:
After duplicating the root folder of the project, open the podfile of the duplicated project:
Podfile
then comment all the previously added pods by adding "#":
Commented Pods
hit CTRL + S in order to save the changes
Open the terminal and change the directory to the folder of the duplicated project and then perform: "pod install". Yes it will delete all the pods but don't worry we will install again in the next step
Pods deletion
Open again podfile and uncomment the previously commented pods:
Uncommented pods
hit CTRL + S to save the changes
Open the terminal and change the directory to the folder of the duplicated project and then perform "pod install". it will install again all the pods:
Pods installation
Finally, run the Project and it should run without any problem.
I recently put several old, yucky git directory structures into one new, clean structure in SVN, then pulled the entire SVN repository back out into a new, clean, local git repository. One IntelliJ project was so messed up I had to import the old IntelliJ project, which created a new .iml file having a better name, and deleted the old .iml file. I reconfigured everything, committed back into SVN, and verified other people could open the project and build.
Today I tried to edit a file for the first time in this project and got the message, "These files do not belong to the project". IntelliJ offers to unlock the file or all non-project files in the current session, but both options sound wrong. What have I done to myself, and how do I fix it?
This happened for me when I ignored the .idea/ files. Just do
rm -rf .idea/
And then File -> Invalidate Caches/Restart -> Invalidate And Restart.
I figured out the problem. The file was still open from before all the shuffling, and was apparently pointing at the original file in its original location! I closed the editor and reopened the file from the project tree without a problem. I hope this helps someone else someday.
From File-> Repair IDE -> Rescan Project Indexes -> Reopen Project worked for me.
Had same problem on Ubuntu (Webstorm), got answer from Intellij.
There are no content roots in your project, so all your files are
treated as non-project files. As I wrote your .idea files are likely
broken, the .iml file and/or modules.xml are either missing or
corrupted. Deleting and re-creating .idea folder should help:
-close the project
-remove it from Recent projects list
-shut down the IDE
-delete the .idea folder
-restart, open the project root folder with File > Open
https://intellij-support.jetbrains.com/hc/en-us/requests/3779670?page=1
This also happened for me when I opened the project through a symlink (parent directory) or when the python interpreter was inside a symlink directory (because of virtualenv).
Reopening through the original directory tree (after fighting hard with the IDE to forget its beloved project settings), solved the issue.
It's probably listed in one of the XML config files in .idea/*.xml.
Just do a find of that folder for the name of the file in question, and remove the entry for it from the XML.
Mine was listed in .idea/workspace.xml within the following node: <component name="TypeScriptGeneratedFilesManager">.
I removed the option, then invalidated caches and restarted, and now the file is marked as a standard, non-generated file again. This way you can keep all your settings without exporting them and importing them.
Similar issue with WebStorm. The difference was I had to shutdown the IDE completely and then remove .idea folder
rm -rf .idea
I tried doing it with the IDE open and going to file File -> Invalidate Caches but that did not fix the problem for me.
Same problem. File was considered not part of the project even if I deleted it and created a new one with the same name.
To fix,I highlighted the project node in the left panel, selected "File/Invalidate caches and restart" from the top menu.
After the restart I had to set my file as a JS file (right click, set as JavaScript), close and reopen the project. All fixed.
For me the above did not help. I ended up going Project Structure -> Modules -> + at the top narrow middle column -> browsed through files to select the Project Folder -> apply -> ok -> all is done and working correctly.
My problem was much simpler than expected: I was trying to run a Jupyter notebook and got the error - because it was inside a folder that was marked "excluded" in the project structure.
Simply moving the notebook out of the excluded folder solved my problem.
In my case it was auto-generated .gitignore, I had entries like:
### npm ###
node
node_modules
frontend-dest
data/
And in project files I had java package called like com.company.test.data which matched last pattern. I strongly recommend to check it before removing .idea/ files and invalidating cache.
This warning is an IDE issue that Android Studio cannot recognise the current directory if it does not include any source files.
So, adding am empty source file, e.g empty_xxx.c under the directory in question and adding below line in CMakeList.txt
add_library(${TARGET_NAME_XXX} SHARED ${SOME_DIR_HAVING_THIS_WARNING}/empty_xxx.c)
will help get rid of this warning.
In my case the above methods didn't help, I just deleted .idea file in project and reset the Jetbrain IDE to default settings and it worked normally.
NB: You will loose all your settings and plugins, but if you don't mind this might help as the last resort like in my case.
I am using Jetbrain,
make sure to include all project files in the project. Use Settings -> project structure.
PyCharm > Preferences > Project > Project Structure > Add Content Root
Somehow PyCharm lost the project root directory in my case
For me it was because I had moved a project to wsl by copying the files from wsl to windows. When I switched branches the file must've been open from before and was the windows version of it and not the wsl one.
I noticed this finally by looking on top of the file tab and seeing the path as C:\User...\filename instead of \\wsl$....\filename.
Close your JetBrains IDE, then open a Terminal window and navigate to your project's root folder, and run these 2 commands:
rm -rf .idea
and then
rm -rf .git
NOTE: you'll probably have to connect your project back to your git repository, so if you have any uncommitted changes make sure to commit and push them beforehand to avoid losing them.
You come at a certain point in the development of every app that what you see in the simulator does not match what you think should happen. Mostly these are human errors -- or at least they are in most of my cases ;-) -- but sometimes Xcode has just 'lost track', or so it seems. I've learnt that the Clean (Shift+Cmd+K) and Clean Build Folder… (Option+Shift+Command+K) menu options can show the difference between your error or Xcode's.
My question though is:
What does the Clean command do or not do, which leaves a reason for Clean Build Folder… to exist? When should I pick one over the other, why not just always clean the whole folder?
If you select Clean from the Product menu, XCode will delete the files inside every folder in the Build folder, if you select Clean Build Folder it will delete the entire Build folder.
After Clean command:
After Clean Build Folder command:
I think you should select Clean Build Folder when you want to build a binary that you want to release to the AppStore, when you messed up with your project or when your app doesn't work for an "unknown" reason, otherwise use Clean.
I hope I've answered your question :D
Clean… cleans the folders for the current selected target.
Clean Build Folder… cleans the folders for all the targets.
As of Xcode 10, 'Clean' has effectively disappeared. Apple says here:
"The new build system uses the "clean build folder" behavior. The legacy "clean" behavior is not supported".
If you select "Clean", Xcode will delete files inside every folder(e.g., Products, Intermediates) in the Build folder, for the current target. Files for other targets remain.
If you select "Clean Build Folder", Xcode will delete the entire Build Folder, so nothing left.
In most cases "Clean" will work for "unknown" reasons, but you still have to "Clean the Build Folder" because Xcode won't delete files in the include folder inside Products folder.
Some files at ~/Library/Developer/Xcode/DerivedData/xxx-ABCD, where xxx is the name of your project or workspace, have been deleted after you Clean or Clean Build Folder.... Obviously, Clean Build Folder... will delete more files than Clean will do. However, I think deletion of the folder that I mentioned before is needed in some case, such as your Xcode cannot work properly.
By the way, something has changed for Xcode 8, Build folder is kept all the same after Clean Build Folder...