How can I omit the source links in JsDoc? - jsdoc

What's the easiest way to cause JsDoc to leave out the source links? Do I have to define my own template?

If you use the default template, then use a configuration file with templates.default.outputSourceFiles set to false. For instance:
{
"templates": {
"default": {
"outputSourceFiles": false
}
}
}
You'd pass the path to this file to jsdoc using the -c option on the command line.
I don't see this option documented in any actual jsdoc documentation. I've found it mentioned in this issue and this one.
The template is the entity providing this functionality so if you use another template than the default one, you have to check its documentation to find whether there is a setting you can set to do this.

In order to remove source file links, we need to create a file named jsdoc.json and add:
{
"templates":{
"default":{
"outputSourceFiles":false
}
}
}
Then run:
jsdoc -c jsdoc.json calculator.js
Here calculator.js is the main file (your actual file that is going to be documented) and jsdoc.json is the configuration file. To run the configuration file I used –c option.
So, basically all you need to do is to just create a file called jsdoc.json and add the above mentioned code and save it. After saving run this command:
jsdoc -c jsdoc.json calculator.js

Related

Yocto: add a statement in the default service file within a recipe

I'd need to add a Restart statement within a default .service file, and was looking to an alternate solution to replacing the .service file with a custom one (which works).
The idea would be just adding the following "delta" requirement in a, e.g., ${systemd_system_unitdir}/my_service.d/override.conf file:
[Service]
Restart=always
and then adding that file in a dedicated .bbappend recipe file.
Tests so far were not successful in adding the above statements in the deployed service file (despite the "delta" conf file being correctly deployed). Is this even a possible solution?
You should be able to do that simply by echoing that entry in a do_install:append() section in you .bbappend file. Something like:
do_install:append() {
echo "[Service]\nRestart=always" >> ${D}${sysconfdir}/wpa_supplicant/...
}
You can equally use sed to find and replace that section if there is already a file inplace.
${sysconfdir} will expanded to /etc. Check this file for more defined path variables: https://git.yoctoproject.org/poky/plain/meta/conf/bitbake.conf?h=blinky

How to specify the AdditionalLibraryDirectories to msbuild?

I'm dealing with a .vcxproj file with the following Link segment:
<Link>
<OutputFile>$(OutDir)$(TargetName)$(TargetExt)</OutputFile>
<SuppressStartupBanner>true</SuppressStartupBanner>
<AdditionalLibraryDirectories>..\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<GenerateDebugInformation>true</GenerateDebugInformation>
<AssemblyDebug>
</AssemblyDebug>
<ProgramDatabaseFile>$(OutDir)$(TargetName).pdb</ProgramDatabaseFile>
<SubSystem>Console</SubSystem>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
<TargetMachine>MachineX86</TargetMachine>
<ImageHasSafeExceptionHandlers>false</ImageHasSafeExceptionHandlers>
</Link>
It would seem, I should be able to add more elements to the linker's LIBPATH by simply adding one more argument to msbuild's command line: /p:AdditionalLibraryDirectories=D:\Foo\lib. Unfortunately, this seems ignored and link.exe is invoked with only the /LIBPATH:..\lib argument...
If I edit the file and replace the %(AdditionalLibraryDirectories)-part with the desired path, things work -- linker is invoked with two /LIBPATH: arguments and the executable gets built.
Why can't I specify it as property on command-line, though?
I'm using Visual Studio 2017, with msbuild announcing itself as "Build Engine version 15.9.21+g9802d43bc3".
You'll need to use a completely separate MSBuild property.
For example, on your command line:
msbuild ... /p:FooLibDir=..\lib
and in the project file:
<AdditionalLibraryDirectories>$(FooLibDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
The reason that setting AdditionalLibraryDirectories on the command line doesn't work, is that the /p command line option for MSBuild sets properties, whereas AdditionalLibraryDirectories is metadata on the Link item (note how the parent of the AdditionalLibraryDirectories tag is a Link tag, not PropertyGroup).
The way to think about the difference is:
A property is a global variable accessible to everything (hence it can be set on the command line).
Metadata is specific to a single item (e.g., what additional directories to search for libs in, when linking this specific .obj).
Metadata in a ItemDefinitionGroup becomes a "template" that each instance of that item will use when declared.

AEM: Issue using Command Line DAM Workflow

I like to execute a command line programm as a DAM workflow. I tried to implement the ImageMagic example from here: Best Practices for Configuring ImageMagick:
I addded a new Workflow Model,
added "command line" from the "DAM Workflow" list.
In the Argument tab set Mime type to "image/jpeg" (even tried wihtout Mime type)
and in Commands: "C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" convert ${file} -flip ${file}-flipped.jpg (instead of magick convet ... because in another discussion using an absolute path instead of global name helped people Re: CommmandLineProcess : ImageMagick)
I then added a luncher. And uploaded an Image to the DAM.
In the workflow > instances overview, i see that the workflow was started, it's running and the command line job is set to active.
Unfortunantly this state is never chnaged and no new asset is generated via imageMagic.
I even tried replacing the command with something simple like "ren C:\test\foo.txt bar.txt" which renames a local file. The chnage never happend either.
My question is what am i doing wrong, and how can i debug / find the command outputs? in \crx-quickstart\logs i couldn't find any logs regarding CommandLineProcess.
Thanx

Netbeans: How to use special project parameters in run command line?

I am trying to run a project that requires a specific file for proper execution. So far I have hard-coded the path to that file in the Run configuration's command line, but I would like to use a special project variable for that, that points to the actual directory the project is in.
Example (run command-line):
Now: /home/user/netbeansproject/myProject/myspecialfile.gz
Expected: ${project.dir}/myspecialfile.gz
Is this possible in Netbeans and if yes: how and where are those parameters documented?
Try this!
if (new File("myspecialfile.gz").exists()) {
System.out.println(new File("myspecialfile.gz").getAbsolutePath());
}
I would pass the path to main method with command line arguments when the application starts.
if (args.length > 0) {
System.out.println(new File(args[0].trim()).getAbsolutePath());
} else {
throw new IllegalArgumentException("Configuration file needed to"
+ " run. Provide configuration file's path as argument.");
}
But maybe this solution is not what you're after.
EDIT:
Well if you define new "Run" configuration in your project properties and save it, then it is saved to ..NetBeansProjects/YOUR_PROJECT_NAME/nbproject/configs/your_configuration_name.properties
In that file you can define your commandline arguments like this:
application.args="/somepath/NetBeansProjects/SomeProjectName/myspecialfile.gz"
I don't believe you can add ${somedir} reference to it.

using property file along with config file to be used with mxmlc

I'm trying to run mxmlc in the following manner.
mxmlc -load-config+=mycfg.xml C:\\projects\\src\\main.mxml -output myswf.swf
In the config file, I want to keep some values configurable, for example the paths of the external libraries. Is it possible to include a property file into the config file and use it as {property_name} in the config file?
Or is it possible to pass certain arguments from the command line itself that will override/replace the corresponding values in the config file, like the -D option in the ant command?
Please provide your suggestions.
From the LiveDocs for mxmlc / -load-config:
If you specify a configuration file,
you can override individual options by
setting them on the command line.