I have spent the days looking for an Opensource JavaDoc editor or a way to edit JavaDocs easily or creating package-info files and come back empty.
I am basically after a way to change the way the packages are listed. The automation framework I work on is undergoing some potential future changes. These changes in a nutshell will organise our test scripts in a way where they are split up into business areas and then into smaller packages of business functions within that area.
We use IntelliJ and the default JavaDoc generator creates the JavaDocs in a way where it makes a list of all the packages, what I want to do is have it create a list of the main packages (business areas) and then the sub packages within that contain our test scripts (business functions).
For example:
BusinessAreaOne contain BusinessFunctionOne, BusinessFunctionTwo and BusinessFunctionThree.
BusinessAreaTwo Contains BusinessFunctionFour and BusinessFunctionFive.
The BusinessFunction packages in turn contain scripts that cover just that business function.
I haven't been able to find an editor that does what I would like and I don't think editing the files manually is practical each time there is an update.
If there is no opensource java editor can do this are there any suggestions of a work around?
As I mentioned I have tried creating package-info files but as far as I can tell you can only add a description to that package. Is there any tutorials out there or does anybody know a way I can get it to display the list of packages within the selected package?
Thanks in advance.
Javadoc doesn't treat package hierarchies as nested hierarchies, it just flattens them all into a list, as you probably noticed, so your business functions will just appear as entries in the list between the business areas.
Looking for a Javadoc editor is not going to help you because the Javadocs you end up with is the output from the Javadoc compilation process, and there's no specific tag you can put in your code that will influence the compilation process in the way you're looking for.
You would have to write something to override Javadoc's implementation of its HTML formatter specifically for the package list using:
Javadoc Doclets
You can customize the content and format of the Javadoc tool's output by using doclets. The Javadoc tool has a default "built-in" doclet, called the standard doclet, that generates HTML-formatted API documentation. You can modify or subclass the standard doclet, or write your own doclet to generate HTML, XML, MIF, RTF or whatever output format you'd like. Information about doclets and their use is at the following locations:
Javadoc Doclets
You would use your own implementation of the Standard Doclet, finding the right class to override - try looking first at the PackageDoc class. I'm going through this learning process myself at the moment, but here's the info on Doclet and there's a link at the bottom of that page to the source code which will illustrate how to do it.
Of course there could be an easier way of doing it and if I discover it I'll come back to update this answer.
Related
I am quite new to Mediawiki and am trying to get templates work.
I managed to get a simple one working but the templates are shown in a weird way but no error is provided.
I looked at your template:
http://wordpress-251650-782015.cloudwaysapps.com/index.php?title=Template:Cita_conferenza
And it invokes a LUA module:
http://wordpress-251650-782015.cloudwaysapps.com/wiki/Modulo:Citazione
You can read more information about using this module on
https://it.wikipedia.org/wiki/Modulo:Citazione
#Revious
A bit late, but you may still be interested...
If you want to copy a template from Wikipedia, but it is using lua modules, you can look in the history tab to find pre-lua versions that use only wikicode (lua has been implemented in 2013 in Wikipedia, but some templates have been given modules later).
Here, it seems to be this version
Be careful, however, if the template you are copying uses subtemplates (this does not seem to be the case here).
If this is the case, you should either make copies of the templates with the same name and code, or add their code to the main template, paying attention to the parameter names which will need to be adapted.
Good luck.
I am creating a MATLAB package using object-oriented programming. I have documented my classes according to a tutorial from MathWorks website. This standard of documentation, however, only works for doc and help commands, but not when I use publish. For example, properties, which have their description written in front of their declaration, don't have said declaration exported to HTML. There is no list of properties or methods at the beginning of the file, so that users can quickly skip to those. Lastly, documentation has to be read directly from the comments in the code, instead of being parsed to HTML.
When I try to add some HTML documentation inside my classes to publish them, the code also appears on doc and help, which is an undesired behavior. Is there a way to create class documentation so that properties and methods can be published to the Web? I've had experience with doc generators like Sphinx (Python) and Doxygen (many languages), in which the descriptions of classes, methods and properties are parsed to HTML so they can be published in places like Read the Docs or GitHub Pages so I am curious to know if MATLAB has something like that.
You can give a try to MTOC++ which uses Doxygen, therefore produces the standard Doxygen HTML documentation.
I have used it already to generate source code documentation for Matlab project containing standard Matlab functions, old class definitions with # notation and classes defined by classdef mixed, and it worked after some tailoring.
This somewhat larger project allows to create documentation for MatLab
files and classes (including packages) using a doxygen filter named
mtoc++. Moreover, a tool/class named MatlabDocMaker allows to create
the documentation from within MatLab. For Windows, Mac and Unix!
You can find it also on Mathworks File Exchange and you can find the documentation here.
One widely-used way to provide HTML documentation for MATLAB functions/class is the M2HTML project. It will automatically generate HTML documentation complete with dependency graphs, source code, and syntax highlighting.
I'm trying to make a starpack like single binary which wrapped a bunch of tcl scripts inside. I looked at the TclApp doc from ActiveTcl, it seems like you have to use their basekit (e.g. /usr/local/ActiveTcl/bin/base-tk8.5-thread-linux-ix86). However, I have built the interpreter into my own binary. How to make my binary a basekit?
I'd start by asking whether it is really necessary to have your own build of Tcl. If you can structure your code so your custom pieces are loadable extensions (linked correctly against the stub library) then you can just use it with a standard kit distribution.
But if your code is such that it really needs to be built as the main executable, you can do what you're after. You probably want to start from Kitgen, which is both maintained and reasonably open. You'll have to do some work to make things assemble correctly; in particular, make sure your code is built with static linking against any external libraries it needs (with the exception of the C library and other things that can reasonably be assumed to be present on the target platform) as the runtime link environment of a kit-based distribution of Tcl is distinctly weird. Building as a stubbed extension (which you can just store inside the kit package) is much simpler to get right.
I am writing some support code in the common subset of Matlab/Octave, which comes in the form of a bunch of functions. Let's call it a package.
I want to be able to organize the package, i.e.,
put all the relevant function files in a single place, where users
are not supposed to store their code;
have some internal organization ('subpackages');
prevent namespace pollution;
have some mechanism for user code to 'import' parts of the package;
I don't necessarily want all functions I provide to be
visible from user clients.
On the Matlab side of things, this functionality is pretty much provided by package directories and the 'import' mechanism. This functionality doesn't appear to be available in Octave though (as of 3.6.1).
Given that, I wonder what options remain for organizing my support code package in Octave.
The option of putting everything in a directory and just have the user code do an ADDPATH feels rather unrefined, and doesn't give the level of control I want -- it only addresses point #1 of the list above.
There is plenty documentation here and examples in OctaveForge. Just browse the SVN.
Also there are personal packages all around. For example this one
Happy coding!
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).