I have a Maven-Project in Eclipse with JUnit4 for Testing. It works well, but I have a question:
In Run Configuration for JUnit is there the tab "Environment" with a lot of variables.
Where are saved these variables? In which path/file can I find/write them?
Or, would be posible to copy-paste all these variables, instead to write manualy each one in this tab?
Thanks for your help, Chris
founded! these are saved not in project-files. they are in
.metadata.plugins\org.eclipse.debug.core.launches\
Related
I've done a fair old bit of searching, so asking here as a last resort!
I know under "File Watchers" there are variables/macros that can be passed into the arguments field like $FileName$
Can this be done with Run/Debug configurations? I've tested with the variables/macros available from File Watchers, but they just get passed directly through to my gulpfile.
If not possible, an alternate approach - is it possible to read the path that a watcher (gulp-watch) has been trigger from?
Many thanks in advance,
No, it's not possible. Generic support for using macros in run configurations was added in 2018.3 (see IDEA-74031), but it has to be implemented separately for each configuration/field. Please feel free to file a request for adding variables support to Gulp run configuration to youtrack, https://youtrack.jetbrains.com/issues/WEB
I have a Nightwatch + BrowserStack configuration on my project and I'm trying to add custom commands to my project to compare 2 screenshots using resemble.js .
I configure my nightwatch.json file with this :
"custom_commands_path": "./node_modules/nightwatch/commands",
"custom_assertions_path": "./node_modules/nightwatch/assertions"
I put the commands file in the folder and I tried to run my test in every directory possible to see if it was a path problem. I've also tried with different commands, some of them I get online and even the default example one. Whatever I run it returns nameOfTheCommand is not a function. So I guess it does not even find the path to the customs commands in the nightwatch.json file.
Is there anything I'm missing here? I'm quite new so the answer could be very simple but I tried every .json file of my project in case there was a special configuration linked to BrowserStack.
Path to the custom commands should be analogous to the path to custom commands. You should point a folder where you added them.
I've found that if I put them in the suite configuration file, it picks them up:
nightwatch_config = {
src_folders: ["tests/suite/product/"],
page_objects_path: "pages/product",
custom_commands_path: "./custom_commands"
}
I am porting over an MSBuild script from CCnet to run in Jenkins. The MSBuild project is used to create a deployment package. I would rather have Jenkins drive this process itself but that's a longer term aim.
The problem i am having is (as in the title) when we try and use the HgPull target, from the MSBuild mecurial task (http://msbuildhg.codeplex.com/) we get the error message
HgProcessException: The command hg.exe is not available [Path to project]
I have seen on the project web site that someone solved it by adding the LibraryLocation proeprty to the target but that seems to have made no difference. My target currently looks like this:
Target Name="UpdateSources">
<HgPull
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Force="true"
Update="true"
LocalPath="$(SourcePath)"
/>
<HgUpdate
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Clean="true"
LocalPath="$(SourcePath)"
/>
I'm rather at a loss. Please let me know if you need any more information added to this post to solve this issue. I'm really quite new to MSBuild so really not sure where to start investigating this.
EDIT:
One thing i forgot to mention was that i have tried running the MSbuild command in a console window on the build server and still get the same result. This is really odd given it works fine in CCNet, what magic is CCNet doing to make this command work?
This is now resolved, unfortunately i'm not sure what changes i made to correct these. I believe it may have been down to path separators and whether they where trailing or not in another part of the config file. It does so annoy me with the lack of resilience/consistency between applications where you need to specify paths with/without trailing slashes.
Just a thought, but try adding 'C:\Program Files\TortoiseHg' to your system path. Maybe CCNet has it specified somewhere that Jenkins doesn't have access to.
Also, just for sanity's sake, verify that hg.exe actually exists at that location.
I am using unitils (and its dbMaintain module) to maintain the state of my local database.
dbMaintain has an option to exclude/include scripts based on a qualifier. See http://www.dbmaintain.org/tutorial.html#Qualifier_inclusion__exclusion.
In my project, excludes/includes do not work when running from a Unitils test with the UnitilsJUnit4TestClassRunner.
My script hierarchy:
unitils/
01_create/ <lots of scripts here>
02_lkups/ <lots of scripts here>
03_#testdata/01_#testdata_master/05_#testdata_master_rate_offer.sql
My unitils.properties file has:
updateDataBaseSchema.enabled=true
dbMaintainer.script.locations=unitils
dbMaintainer.qualifiers=testdata
dbMaintainer.excludedQualifiers=testdata
I would expect 05_#testdata_master_rate_offer.sql to be excluded. But it is being run.
Thanks in advance for any help.
Answered by one of the unitils developers on the unitils forums here: http://sourceforge.net/projects/unitils/forums/forum/570578/topic/4546980
Qualifiers are a feature of
dbmaintain. Unitils 3.1still contains
its own dbmaintainer which still dates
from before the split-off of
dbmaintain. Unitils 4.0 has this
module replaced by a dependency to
dbmaintain, but this version is not
released yet. I would suggest that,
until 4.0 is released, you call
dbmaintain directly from your java
code. Hope this helps, Filip
Just about everything in my documentation ends up with the namespace:: prefix in front of it. (where namespace is the name of my namespace)
Is there a way to have the documentation generated without the namespace part?
For example:
my_namespace::myclass::member
becomes:
myclass::member
It would make everything more readable.
Turns out the answer was simple: you have to set HIDE_SCOPE_NAMES to YES in the configuration file.
I know this is old but if anyone comes looking again.
You can set SHOW_NAMESPACES to NO in configuration file.
It is also in DoxyWizard, Expert tab under Build topic.