To write multiple feature files(.feature) and respective step definition(.rb) files for my current Calabash project directory. Here, My doubt is that
a. Do I need to create feature file manually by using text editor after default single feature file creation based on calabash cmd 'calabash-android gen'?
b. Should I use my IDE to add multiple feature file and step definition files into Project skeleton?(I'm using Visual Studio Code IDE)
a. For your first feature you can reuse the file that is created if you want to. After that you should create a new file for each feature you want to test.
When you execute the tests you will often only execute 1 feature test at a time while developing and perhaps only from a certain line number. So having the tests split in multiple fetaures works well.
You have probably read it but if not please take a look at the Github page.
b. You can create the files any way you want to. I normally copy an existing feature file through IDE and clean it. Personally I find JetBrains Rubymine to be a really good IDE for working with Calabash.
Related
I have a bootloader project and an app project within the same workspace in Eclipse.
I'd like to merge the hex files of theses two project into one single hex, so that I can flash in my MCU both project at the same time.
I know this is possible using some tools (https://www.keil.com/support/docs/2666.htm), but I would like that the merge process happens in Eclipse using a post-build command or else.
Thanks
Intel hex are just text files, you can merge them manually in any text editor by using simple copy/paste. Grab the data rows only from one of the files.
This assuming that there's no CRC on the program as whole. Also, you probably shouldn't have multiple rows with the same address in the same file or you might confuse some tools.
I'd recommend doing this through a diff tool such as for example WinMerge, or the one integrated in your version control system. Once you have it working you could write a file handling script for merging them automatically.
As an avid user of processing in my spare time, I often find myself writing more than 10 classes in a project, which of course overflows the class bar at the top of the processing IDE and makes it hard to work on all the classes in a project. The solution in any other language is to create class libraries (.net), packages (java), etc. which is not possible from within the processing IDE (It just won't accept .pde files in subfolders).
I tried using Eclipse and importing processing but it makes everything a little more messy as you have to extend Papplet and pass it in to every class that you create and then you have to say parent.rect() or something similar when you want to use Papplet methods which is just one step more than I am willing to go on every new project.
Now, I often use processing from VSCode since i prefer the IDE and i can still compile and debug just as easy from VSCode as Processing IDE, and one day i thought to myself, what if, rather than that horrible solution of using Eclipse, I have the following:
All .pde files are in the one directory (just how processing wants it) but I have an extension for VSCode that takes my files and displays them as if they were in folders within VSCode, There are no changes to the file structure, only the way they are visible to me within the IDE, this way I can comfortably see each of my files and manage larger projects!
So the project folder would look like This in file explorer
But would look like This in VSCode
So finally, my question is -> Is there some sort of extension that I can get that will do this, if not, any suggestions on where i should start in creating one?
I need to copy a file after saving it to another directory - how can I achieve this? My first attempt is to use an ant builder that always (after a clean, after a build ...) copies all files of my project to the target directory. This works fine but if you have 1000 and more of files in your project, it gets to slow. So I just want to automatically copy the file that I've just edited/created to a specific directory.
http://andrei.gmxhome.de/filesync/index.html
This is a filesync plugin for eclipse. Pretty fast and incremental. I always use it for such cases. You define mapping, and it is a native (java) builder, that is assigned to your project. Works with path variables as well, if you need to achieve workstation independent settings.
ps:
What do you use it for? Since I recently used it, but I realized, this is usually evil thing :) Do you tell me the use-case for this?
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.
I often have to open a secondary editor outside of Netbeans in order to work on temporary bits of text outside of my project files. Is there a way to create temporary files in Netbeans without adding them to a project?
File -> New expects every file to be part of a project.
I know this has already been answered successfully, but there is now a proper Netbeans plugin for this requirement: http://code.google.com/p/netbeans-scratchpad-plugin/ It works nicely for me and allows multiple scratchpads which can be handy.
Also note that the Copy/Paste History plugin which is available by default (with NB7 at least) is handy for this too.
HTH,
JD
By default, there is no such feature yet (I'm using 6.5).
You could include a folder in the Favorites window, and right click > New > Empty File from the folder, it won't be part of the project.