I was using ANT before (Android Project) and i had "static" files in the same packages as my code
Here is an example
src/com/my/app/test/Parser.java
src/com/my/app/test/json_to_parse.json
When executing the unit tests, the json file was copied into the gen folder, therfor it was possible to access the json in the test with
getClass().getResourceAsStream(fileName)
I had to convert the project to gradle, but now the tests are failing.
After checking the "build" folder, i've realised, the .json files are not there, therefor the getResourceAsStream method returns null.
Any idea how to include these "static" files (json, xml, ...) into the build folder?
Moving the files into the resources folder did not work out of the box in Android Studio (even though is should have)
This should be fixed in Android Studio 1.2.
However, this is what i did:
Moved all static files into the resources folder.
In my unit-test module i've added this to the build.gradle file
task copyTestResources(type: Copy) {
from "${projectDir}/src/test/resources"
into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources
Now, all files located inside src/test/resources will be copied into /classes/test where i can access them with
getClass().getResourceAsStream(fileName)
If i keep the package structure inside the resources folder the same as it was in the java folder, i don't need to adjust any code.
To complete the story a bit more:
JUnit4 runner requires
getClass().getResourceAsStream(name)
while Robolectric requires
getClass().getClassLoader().getResourceAsStream(name)
The files you are asking about are called "resource files" in Maven/Gradle lingo.
Gradle assumes that you are using the Maven Standard Directory Layout.
So, either you move your files into src/test/resources (then Gradle will pick them up automatically), or you tell Gradle that it should look for resources in some other place.
In the latter case, you need to modify the processTestResources task. However, keeping resource files in the same directory as source code is a bad practice. So I advise the former option.
if your problem is happen when you create apk with AndroidStudio.
you can create a jar file that includes your resources with jar.exe
for example i put a.txt into resources directory
and run this code in cmd:
"C:\Program Files\Java\jdk1.7.0_79\bin\jar" cvfe res.jar -c resources
after that a jar file "res.jar" was created
then add that res.jar into libs folder in your project
when your apk is creating resources are added to your final apk and you can use this code to acsess a.txt:
someclass.class.getClassLoader().getResourceAsStream("resources/a.txt");
with this job no need to change Gradle setting.
Related
I have converted one of our Android projects from the old Groovy settings.gradle and build.gradle files to the new Kotlin DSL, i. e. settings.gradle.kts and build.gradle.kts.
While "it works on my machine" - in particular: the original project I converted from Groovy to Kotlin works fine in its original directory - all my co-workers are unable to open the project when they clone the repo. Importantly, neither can I open the project myself (with the same AS installation on the same machine) when I clone the repo to some other directory. So, I suspect there is some additional detail missing in some configuration file but I cannot seem to figure out which...
Details:
When I just use File > Open... and then select the project folder, I only get the error message "The project 'xxx' is not a Gradle-based project"
When I instead go through Import Project (Gradle, Eclipse ADT, etc.) and then select Import project from external model and Android Gradle Android Studio will create an empty build.gradle file and fail with the error message "ERROR: Plugin with id 'com.android.library' not found." Deleting the build.gradle just goes back to the error message I described in the first bullet point.
I am aware of this Github issue, which seems to describe the same problem, but it's been very quiet and I thought someone around here must have figured out a solution to this...
Oh, command line builds work everywhere - this is purely an Android Studio problem.
UPDATE: When I copy the whole project to a new folder (instead of cloning the repository) I can open it without any problems. So, am I correct in assuming that there must be something inside the folder - but not in Git - that makes it work?
I was able to 'fix' it by deleting the .idea directory and reopening the project. The .idea directory is usually not committed in git but I guess copying the directory invalidates the directory structures in the files within the .idea directory.
The whole bug is easily reproducible when you click on File > Re-import Gradle project.
#Boni2k answer does not work for me.
I have to rename the root build.gradle.kts back to build.gradle, fix the syntax error, sync the project (which works fine immediately), and rename the file back to build.gradle.kts. Then the error is gone and I can sync the project successfully.
What I did to raise the error was that I moved the project to a different folder, and rename the project.
I've created a Flutter app in Android Studio and I want to change the name of the "lib" directory (in which Dart source files reside) to "src".
However when I do that, the import to 'package:/main.dart' fails. How can I change that?
I changed the path in the .iml file, and the project compiles and runs, but this test file still shows an error.
This name is hardcoded and there is no way to change it.
The whole pub package system depends on that directory name.
There is also a convention that tools like the analyzer support code in lib/src being considered package-private when not exported by files in other directories in lib/.
Im setting up a unit test project and using SVN for source control. There are two nuget packages used. Im not sure if I need to exclude the files being generated or not.
MSTest.TestAdapter.1.2.0 and MSTest.TestFramework.1.2.0
When I go to commit the files within my branch, I see a lot of what look like new files being added in this folder MSTest.TestAdapter.1.2.0/build. eg.
MSTest.TestAdapter.1.2.0/build
MSTest.TestAdapter.1.2.0/build/_common/Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll
Can I exclude everything from build/* ?
As a rule of thumb, you shouldn't keep Nuget packages in svn. In Visual Studio 2017 they are not event located in your project folder structure, but in %HOME%\.nuget\packages. Reference: Should we include Nuget PACKAGE folder in version control?
I would add whole packages folder to ignored if I were you.
I have a Team Foundation Build server behind a firewall, and I would like to check in a node_modules/ directory (powering both a Browserify client app and Node server app) associated with a project so that all of the files and dependencies needed to deploy a build are available without fetching anything.
Checking node_modules/ in to TFS seemed to work at first, except that the bin/ directories appearing in around 20 of my NPM dependencies were not checked in. bin/ does not appear in my .tfignore (or anywhere else I know of that could be preventing the check in).
These bin/ directories don't appear in the included/excluded changes in Team Explorer, at all. It's possible to locate one of these folders in Windows Explorer and add it with the TFS context menu, but doing that for all of the dependencies would be horrifically tedious and error prone.
How can I persuade TFS to detect changes in these folders? Is there some other configuration affecting included/excluded changes that I'm not aware of?
It is not recommended to upload "bin" folder or "node_modules" folder into Version Control. But if you do want to do this, following the steps below:
Go to "C:\Users\youraccount\AppData\Local\Microsoft\Team Foundation\x.0\Configuration\VersionControl" folder and open "LocalItemExclusions.config" file. (There may several folders named like 1.0, 2.0, 3.0, you need to make sure open the folder your VS current use.)
Delete the lines like following and save the file:
<Exclusion>bin</Exclusion>
<Exclusion>*.dll</Exclusion>
Close Visual Studio.
Delete "node_modules" folder.
Restart Visual Studio.
Run "npm install" command to reinstall the node modules.
Check "Pending Changes", files in "bin" folder should be listed in "Excluded Changes" section.
To check if the files and bin folders will get ignored by TFS. You could try to manually add them (such as drag to source control explorer). If you couldn't, then must related to some .tfignore settings , you may double check this such as if there is a .tfignore file in the root of the project folder level.
If you could, there maybe something wrong with your workspace or source control mapping of the bin folder. Try to remove the source control bindings and rebinding to TFS. Also give a try with delete the old workspace and use a new workspace.
You shouldn't check in node_modules - ever.
Rather use browserify or WebPack (I'd recommend WebPack) to package up your bundle.js.
Add the bundle.js to your source/scripts folder. Reference your bundle.js from your html instead of any <../node_modules/../scripts>.
Remove the npm install from your build script. you won't need it now due to referencing your bundle.js
WebPack is a dev-step, but it secures the version of packages you used during development and also saves you the npm install headache during deployment.
I have an Azure cloud service project to which I am adding a cache worker role. While local build goes through fine, I get the following error on my server builds :
CloudServices38 : The entrypoint dll is not defined for worker role <cachename>
What is wrong? How do I fix this?
Make sure all the Azure DLLs are marked Copy Local = True in the properties window. Also, package your projects, then unzip them. Once you build the package, you will have a file YourProject.cspkg. Change the extension from .cspkg to .zip and extract the files. In these files you should see a file with the extension .cssx YourProject_.cssx. Change the extension from .cssx to .zip and extract again. You project that is deployed will be in the folder YourProject\sitesroot\0 - verufy all the files you are expecting (i.e. content and everything that is in the bin directory on your local build.
You need to run a Build and a Publish separately. I ran into the same problem on my project and this fixed it.
1) Visual Studio Build (or MSBuild) action with arguments /t:Build (clean here)
2) Visual Studio Build (or MSBuild) action with arguments /t:Publish (do not clean here)
Note: I had to run these actions separately (not /Build;Publish) otherwise I got an error about the cloud service entry point.
Pieced this together from this question and from here and here.