I'm looking for GnuRadio Companion OOT schema documentation. I saw this post and I'm not satisfied. I saw something more like a tutorial about YAML and XML:
https://wiki.gnuradio.org/index.php/YAML_GRC
https://wiki.gnuradio.org/index.php/XML_GRC
This is definitely not what I'm looking for. I'm looking for a place where I can find all possible options and parameters/attributes to set. There aren't e.g. "tab" or "option" parameters for the "param" option from XML over there. I would also like to have something similar for YAML.
This is a bit hard to answer in closed form, but essentially, we have a schema checker, and it contains lists of the acceptable YAML properties:
https://github.com/gnuradio/gnuradio/tree/master/grc/core/schema_checker
Related
I have a custom XML format that links to Java resources. For the sake of simplicity let's assume my XML file would look like this:
<root>
<java-class>my.fully.qualified.class.name</java-class>
</root>
Eventually my references will be somewhat more complicated. It will not contain the fully qualified class name directly and I will need some logic to resolve the correct class, but I want to keep the example as simple as possible here.
Now I want it to be possible to Strg+Click on the element's text and want IntelliJ to carry me to the .java file, just like it is possible in Spring-XML files. In the IDEA Plugin Development FAQ there is a link called "How do I add custom references to Java elements in XML files?" which so much sounds like exactly what I need. Unfortunately it links to a discussion where someone is more or less done implementing something like this, having some minor problems. Nevertheless I understood that I probably need to write an implementation of the interface com.intellij.psi.PsiReference. Googling for "PsiReference" and "IntelliJ" or "IDEA" unfortunately did not bring up any tutorials on how to use it, but I found the class XmlValueReference which sounds useful. Yet again googling for "XmlValueReference" did not turn up anything useful on how to use the class. At least the PSI Cookbook tells me that I can find the Java class by using JavaPsiFacade.findClass(). I'd be thankful for any tutorials, hints and the like, that tell the correct usage.
The above linked discussion mentions that I need to call registry.registerReferenceProvider(XmlTag.class, provider) in order to register my provider once I eventually managed to implement it, but of which type is "registry" and where do I get it from?
First of all, here's a nice tutorial that came up a few days ago, which explains the basics of IntelliJ plugin development (you should take a look at the section Reference Contributor).
You will likely have to define your own PsiReferenceContributor, which will be referenced in your plugin.xml like this:
<psi.referenceContributor implementation="com.yourplugin.YourReferenceContributor"/>
In your reference contributor, there's a method registerReferenceProviders(PsiReferenceRegistrar) where you will be able to call registry.registerReferenceProvider(XmlTag.class, provider).
Finally, in your instance of PsiReferenceProvider, you will have to test the tag name to filter out tags which don't contain class references, then find the right Java class using JavaPsiFacade.findClass().
From my experience, the best place to get help regarding IntelliJ plugin development is JetBrains' forums.
For me to execute something at the TestRun, Feature, Scenario or Step level.. I understand we can use Hooks. What i would like to find out is how these can be writte in the feature file when I am writting the spec.
Based on my understanding I can use Backgroud to write something common which is to be run within the feature before all the scenarios. However its adviced that we should not have long list in the Backgroud section. Also if I have something which is common for the testrun or multiple feature where i can use a tag a group them, is there any syntax I can use to write this.
The hook implementations cannot be expressed in Gherkin in the feature files, they must be implemented in the step implementation files:
Tag the scenarios and/or features with a tag #foo, and in some class decorated with the [Binding] attribute, annotate a method with a hook attribute, like [BeforeTestRun("foo")].
More information and available hooks can be found in the specflow wiki.
If you're worried about having a long list of steps in the Background, maybe the steps are too verbose and you can consider joining them into a single step. If you need to do something for all tests in the test run, maybe it's not important to mention it in the feature anyways, so it can go in a step implementation file like described above.
Any ideas on how to include the xsd:annotation and xsd:documentation content defined in the schema as javadoc in the generated pojo using jibx???
For now I only get the schema fragment on top of the class but cant see the annotation documentation for the schema.
thanks for you time.
You seem to be experiencing an unexpected behavior, unless the lack of details in your question threw this answer off... If you're still in a bind after attempting troubleshooting as described below, the best would be for you to update your request with more information, such as an XSD fragment showing the setup, the versions you're using (Java, JiBX) and the command line you use for your codegen utility.
Start by taking a look at customizations documentation; make sure that the import-docs option, which is responsible to "Convert xs:documentation annotations in the schema definition to Javadocs in the generated [...]", is not set to false. The default value is true, so it should work...
Check that from a command line perspective, you're not overriding it. Alternatively, you could ensure is set explicitly (see this).
JiBX does automatically includes xsd:documentation content in the generated source code which will end up in your javadocs.
For a nice example, take a look at the opentravel.org schema which is included in the JiBX schema library.
Here is the opentravel schema definition for a 'ping' message:
http://opentravel.org/2011B/OTA_PingRQ.xsd.
Now download and unzip the javadoc.jar for the generated code from maven central:
http://search.maven.org/#search%7Cga%7C1%7Cfc%3Aorg.jibx.schema.org.opentravel._2011B.ping.PingRQ
Notice how the xsd:documentation displays nicely in the javadoc.
Hope this example helps!
Don Corley
JiBX contributor
I'm new to Doxygen and I'm trying to document an API I am planning to open source. I'd really like to build two sets of documentation, one for end users of the API and one for those who intend to modify it. Is there a way to tag Doxygen comment blocks in a way such that I can generate "user" and "dev" documentation trees? Is there a better solution to my problem? Thanks!
Depending on how your code is structured, you might be able to get away with using two Doxygen config files each including separate source files. The "user" config file would only list the source files containing the public interface to the API, while the "dev" config file would list all source files for the whole project.
This does mean that all your interfaces (e.g. abstract base classes) will need to be documented with the user in mind, but that is usually not a problem as by definition there is unlikely to be any implementation details in an abstract base class.
All your "dev" documentation then sits in the actual classes implementing the interfaces, which are never seen by the API and can be safely omitted by the "user" Doxygen config file.
Of course if your code isn't structured this way it's not going to work, so the only solution I can think of is to fill your comments with a bunch of conditional statements.
In addition to what Malvineous already said, there is the \internal doxygen command.
\internal lets you hide or show part of the documentation by changing INTERNAL_DOCS in the Doxyfile
More information here: http://www.doxygen.nl/manual/commands.html#cmdinternal
We've got a large codebase of Java (with a smattering of Groovy mixed in) that, by and large, has no javadocs written for it.
However, much of the code is reasonably well documented in "old-school" comments scattered throughout the body.
We're now on something of a push to try and get things documented a little better - Javadocs are now being generated on a regular basis, for example. As a stopgap measure, it would be really nice if javadoc would "scrape" the body of the class (or function, or whatever) and toss all the comments within into a "stub" javadoc.
Is there a way to do that?
Sounds like a bad idea, given that javadocs typically describe purpose and usage of elements, and code body comments are (or should be) about the details of implementation.
But if you must, you clearly need to write your own custom doclet that works in concert with a java source file parser (either 3rd party or your own). For each processed class, you would first run the parser on the source file for that given java class and harvest the internal comments, and then augment the (standard) html produced by the (standard) doclet to add the code comments.
A possible strategy that would help make the resultant javadocs sensible would be to include a given method's internal comments for the javadoc for that method. Just use a 'pre' closure and append the parsed comments of the method at the end of the generic javadoc html.