I would like to know if there is any possibility to embed mediawiki pages in the javadoc view in eclipse?
We maintain a wiki with informations related to our modules, some functionality, specific problems that were encountered and other stuff. I would like to bring this documentation closer to our codebase. Moving everything from the wiki to javadoc is not possible, because the wiki is also accessible to people, who do not access code and there is also a lack of support for images in javadoc.
I thought of something like displaying the wikipage that is named like the class, whos javadoc I am currently viewing or using special javadoc tags.
Thanks for answers
you could add Links in your JavaDoc to your wiki with html-code. You can use the links without the #see tag, so it is not listed at the bottom of your doc.
/**
* #see http://google.com
*/
you can open the links in the JavaDoc-View in Eclipse, so it will not ne opened in the source-view.
Related
In a documentation page in one project, I need to put a link to an external library's Doxygen mainpage.
I found this: Link to external mainpage
However, it is six years old and I'm hoping that the issue raised in the comments of the answer has been fixed by now, but can find no reference to this in any documentation or anywhere else on the internet.
The only thing I can think may work would be something like:
[link](#ref ExternalProjectName)
However: (1) external projects may have spaces in their name; and (2) is this even a reference name that can be used?
What reference name can I use for the mainpage of another project?
I would like to create a wiki page that is a preamble (standard markdown) followed by an HTML/JS code listing followed by (in a frame I suppose) the page that this code would generate.
Is this possible?
PS The code is: http://pipad.org/MathBox/slides_simple.html
Github Wikis allow you to embed HTML, but not all HTML tags are supported.
To embed supported HTML:
Edit a wiki page.
Ensure the edit mode is on "Markdown".
Type the html directly into the main content area (there's no "code" view, like you often see in tools like Wordpress).
Which tags aren't supported?
I couldn't find documentation on this, but we have a few clues:
Github wikis are built on a software tool called Gollum. We can see which tags are supported in Gollum by default here in the Gollum docs. Github may customize these defaults for their use-case, but I'll bet it's pretty similar.
I went ahead and created a test wiki here with all the major visual html elements added to it (copied from Poor Man's Styleguide). It looks like the main tags that don't display are iframe, video, audio, and all of the various form inputs (textarea, input, select, etc).
Doxygen lets you produce man page output, but as far as I can tell it only generates man pages for the actual code (functions, classes, etc). I have a great deal of information, such as examples, in a doxygen #mainpage comment that is not showing up anywhere in the man page output. I'd like to have it in that format so that I'll also have a man page that serves as an overall introduction. Is there a way of doing this with doxygen?
So far I have not found a way and the alternatives that I've explored don't work very well with the index.html file that doxygen creates for me. For example, I tried several different html2man scripts on the index.html file without success.
I came up with this work-around, which puts the pseudo-mainpage text in the man page, and puts a nice link to it from the HTML mainpage:
/**
* #mainpage
* Summary of my simple project. Please see #ref foo.h for more details.
*
* #file foo.h
* #brief Summary of my simple project.
*
* Here is the much more detailed description of my project,
* originally intended for the main page. Since I value the quality
* of man page output the most, this will end up on the individual
* file man page, and will be linked to from the HTML main page.
* I can rattle on with other things like...
* #todo find a better solution to the mainpage problem.
*/
As far as I can tell, this is not possible. HTML output covers the entire project, whereas man page output covers a single #file. The #mainpage applies to an entire project, not any particular #file. Therefore doxygen doesn't output the #mainpage for man output.
I downloaded the source, and browsed src/layout.cpp. Search (for example) for BriefDesc, and you will see how each "layout handler" is put together. I don't yet understand what #mainpage maps to, but clearly it's not something that's added in the "file layout handlers" section.
I tried adding #mainpage or #page, and using #ref to reference it, to see if I could create 2 man pages and manually tie them together and yet still have a nice HTML front page. For example, I tried to get 2 man pages, foo and foo-intro. To do this, I needed #page. But for HTML output, the intro shows up under "Related Pages", not "Main Page". And yet #mainpage can't seem to trigger a separate man page. Not ideal.
Have you included a #file <filename> comment in the file that holds the #main documentation and does <filename> definitely match the actual file name?
Doxygen will not include documentation from a file that does not have at least this.`
http://www.doxygen.nl/manual/commands.html#cmdfile
I am trying to use Dokuwiki for creating a software user manual, given that I have to create 3 user manuals for the same product in different platform and the changes is very less. Is there any way in Dokuwiki to create a common user manual that can be used for different products?
For the specifics of DokuWiki I'd recommend the site export plugin (primarily because I made it and we use it for our documentation as well).
You can create the chapters of your book just like a normal page in your wiki. When it comes to combining them into different books, create a page called "toc" in a different namespace. In there have the following syntax (see the github page for details):
* [[namespace:chapter1]]
* [[namespace:chapter1.1]]
* [[namespace:chapter1.2]]
* [[namespace:chapter2]]
* [[namespace:chapter2.1]]
* [[namespace:chapter2.2]]
Now you can export this namespace with the roc option enabled - and merged into one document. You could also use the PDF export with custom book-like styles now (this is what we do primarily).
This answer applies to any wiki engine, not just DokuWiki.
Basically, what you need to do is factor out the common part of the documentation into separate pages that can be included in the product-specific pages. For DokuWiki this requires the include plugin (www.dokuwiki.org/plugin:include), although transclusion is often core functionality for a wiki. I'd suggest starting to write documentation for the most common product and then go back to see what portions of that can be pulled out to use for the common documentation.
I'd like to create a plugin that exports into a custom document format similar to the way that export to PDF and export to Word currently work in Confluence.
Does anyone have experience creating a custom export plugin for Confluence? If so do you know of any resources or samples that describe what would be involved?
Here are the most useful resources that I've found so far:
Plugin Tutorial - Adding a custom action to Confluence - This shows how to add an action to the "Tools" menu that appears at the top of a confluence page. Additionally it shows how to interact with the Page object to get more info about the page.
Plugin Module Types - The second guide I found helpful was the list of general plugin module types. It was informative to discover that a "plugin" is really a collection of "modules" and seeing this list was helpful to understand how to apply that model to creating a plugin of the type I was looking for. Additionally the Confluence Plugin Guide was also helpful for a breakdown on Confluence specific plugin modules.
The Confluence Developer FAQ - Useful for information on how to convert wiki content from a page into HTML as well as a number of other hard-to-find gems.
Finally, it was hard to find, but in order to understand how to "target" a particular menu or area of the existing UI to extend, I found it very helpful to read about the guide for Creating your Plugin Descriptor.