The following Greasemonkey userscript will add an incremental search feature to any JavaDoc displayed in the browser.

http://www.teria.com/~koseki/tools/gm/javadoc_isearch/index.html

In order to use the script you’ll need the Greasemonkey addon, too: https://addons.mozilla.org/de/firefox/addon/748

If you create your Javadocs you sometimes get unresolved reference warnings: package xy does not exist or cannot find symbol

If you define the path with these dependencies outside of the target you could reference that path using the classpathref attribute.

But if the path definition is done in an other target and you don’t want to have a dependency on that (e.g. many dependencies are downloaded there, e.g. using Ivy), using the classpathref would throw a BuildException because the path is not defined: Reference my-path.reference not found.

You could do a little hack: use a classpath attribute and use a special PropertyEvaluator for using that path: classpathref=”${toString:my-path.reference}”. If your defining target is executed before, the toString: resolves that into a usable path-string. If the target is not executed before, the resulting string toString:my-path.reference is just ignored by the javadoc task.

Let’s assume you got a date representing as a String e.g. 2009-04-23T11:07:00. Now you want to convert this String into a Date object. This could be done by the class SimpleDateFormat. To use this class you have to pass the date and time format specified by a pattern string. All the possible pattern letters and some examples could be found on the Javadoc site.

Here is a simple example:

 final String dateFormatString = "yyyy-MM-dd'T'HH:mm:ss";
 final SimpleDateFormat sdf = new SimpleDateFormat(dateFormatString);
 final Date date = sdf.parse("2009-04-23T11:07:00")

If you use SimpleDateFormat then you should probably consider some pitfalls.

What is NCSS ?

Non Commenting Source Statements (NCSS).

Yes. What happens today I wanted to measure KLOC
lines for our project. We do development on windows so I got very
limited search results w/o cygwin environment. (I really missing my
Linux box)

Here JAVANCSS came to rescue me.

From ANT TASK you can export result in txt / xml format.

Also if you are not put right path for outputfile then task will not complain but dump all o/p to console.

<target name=”javancss” description=”Counts JAVANCSS”>
<taskdef name=”javancss” classname=”javancss.JavancssAntTask”>
<classpath><pathelement location=”${javancss.path}/ccl.jar” />
<pathelement location=”${javancss.path}/javacc.jar” />
<pathelement location=”${javancss.path}/javancss.jar” />
<pathelement location=”${javancss.path}/jhbasic.jar” />
</classpath>
</taskdef>

<javancss srcdir=”JavaSource” abortOnFail=”false”
ccnPerFuncMax=”10″ includes=”**/*.java”
generateReport=”true”
outputfile=”${basedir}/javancss_metrics.xml”
format=”xml”/>

<style in=”${basedir}/javancss_metrics.xml”
out=”${basedir}/javancss_metrics.html”
style=”${basedir}/javancss2html.xsl” />

</target>

Now here javancss.path is defined in property file & it is path to lib; in my case javancss.path=D:/opt/javancss-32.53/lib.

By default you can export to html. You have to run either style / xslt ant task to create HTML report from xml. You can find different xsl in xslt directory of JAVANCSS download.

Further this tool can give summary report not only NCSS for project but can give drill-down to method level. Similarly this tool can generate reports like following.

Again this is only consolidated report. You can view Average Objects & Functions reports.

Average Object NCSS:                 24.25
Average Object Functions:            09.64
Average Object Inner Classes:         0.01
Average Object Javadoc Comments:     08.56
Program NCSS:                    9,519.00

Average Function NCSS:       2.48
Average Function CCN:        1.20
Average Function JVDC:       0.92
Program NCSS:           9,519.00

NOTE: This data is garbled. But text report gives such kind of report.

All features of JavaNCSS listed below:

1. Metrics can be applied to global-, class-, or function-level.
2. Non Commenting Source Statements (NCSS).
3. Cyclomatic Complexity Number (McCabe metric).
4. Packages, classes, functions and inner classes are counted.
5. Number of formal Javadoc comments per class and method.
6. Average values are calculated.
7. Command line driven.
8. A GUI is provided for better output browsing as well as the integration of JavaNCSS in a project manager and class browser named Jacob for easy selection of input source files.
9. XML output (optional).
10. XSLT stylesheets provided for further generation of HTML, and SVG reports and as a basis for your own custom reports.
11. Ant task (written by Steve Jernigan).
12. Support for Java 1.5 syntax (generics, enums, etc.).
13. 100% Pure Java.
14. Free software (GNU GPL).

JavaDoc es un documentador creado por la compañia Sun MicroSystem en formato html.

Las etiquetas se ponen en la parte de los comentarios los cuales inician con /** y terminan con */ y todas son precedidas por: @.

Por ejemplo:

/**

* Este es un comentario de documentación

* @etiqueta parametro

*/

Entre sus etiquetas tenemos las siguientes:

author: Aqui como podemos intuir ponemos el nombre del autor de la aplicación.

deprecated: Esta etiqueta es utilizada para indicar que la clase o metodo es algo antigua y no se recomienda su uso porque posiblemente sea descontinuada.

exception: funciona como thows.

param: Definición de un parametro de un método, es necesario utilizar una etiqueta para cada parametro.

return: Nos indica el valor resultante de algun metodo, por lo tanto no se puede utilizar en constructores ni en metodos “void” ya que ninguno de los dos regresa valores.

see: Asocia con otro método o clase; es decir, se añade un link en la parte de “see also”.

serial: Se usa para indicar que campos pueden ser serializables.

since: Indica desde cuando se creo ese método, clase o paquete.

throws: Excepción lanzada por el método, se escribe el nombre de la clase y enseguida la descripción.

version: Aquí ponemos la versión de nuestro software.

package hola_mundo;

/**
*
* @author yarull
* @version 1.0 beta
* @since 30/08/2009
*/
public class Main {

/**
* @param args Aqui explicamos para que sirve el
*             parametro de la siguiente funcion
*/
public static void main(String[] args) {
System.out.println("Hola mundo");
}
}

Pour diverses raisons un programmeur doit rédiger une documentation pour ses applications, cette tâche peut s’avérer très fastidieuse et rébarbative.

Étant actuellement en stage, je n’échappe pas à cette obligation de fournir une documentation technique qui servira les gens qui s’occuperont du maintient de l’application après mon départ, d’autant plus que mon travail s’inscrit dans un cadre OpenSource.

A l’université j’ai principalement appris à développer en JAVA, ce langage a la particularité d’intégrer par défaut un générateur de documentation nommé Javadoc, il est simple d’utilisation et donne un bon résultat. Par contre, sous PHP il n’y a pas de générateur de documentation inclus par défaut, j’ai donc comparé les différents outils disponibles sur la toile et mon choix c’est très vite porté vers Doxygen qui permet de générer de la documentation pour des programmes en PHP mais aussi des programmes en C/C++, JAVA, C#, Python,…etc.

Un des avantages non négligeables en ce qui me concerne est la possibilité d’utiliser avec Doxygen la même syntaxe que celle de Javadoc, ce qui est fort agréable quand on est déjà habitué à cet outil. Il y a aussi d’autres avantages comme : support de divers formats de sortie (PDF, XML, HTML…etc), templates personnalisables, tags personnalisables…etc.

Doxygen est donc un outil que je vous conseille fortement, je n’ai pas encore étudié le cas de Python mais si celui-ci ne dispose pas d’un outil standard,  j’utiliserai surement Doxygen pour la documentation de la partie Python de mon projet.

Site officiel : http://www.stack.nl/~dimitri/doxygen/index.html

J’ai achevé l’interface graphique du module ce matin. Il est donc maintenant possible de passer de l’interface par défaut à l’interface focus, en cliquant sur une vignette vidéo quelconque, et de repasser à l’interface par défaut en cliquant sur la vignette vidéo qui est en mode focus. J’ai rencontré quelques petite soucis pour le second passage de l’interface par défaut à l’interface focus, mais cela était simplement dû à la façon dont j’effaçais les conteneurs vidéo de la liste des vignettes vidéo.

Étant donné que l’équipe de développement souhaiterait que le code soit un minimum documenté, j’ai réalisé aujourd’hui une bonne partie de la Javadoc, et j’ai entamé mon diagramme de classe sous Dia. Je devrais également réaliser un diagramme de séquence.

From Wikipedia, the free encyclopedia

A documentation generator is a programming tool that generates documentation intended for programmers (API documentation) or end users (End-user Guide), or both, from a set of specially commented source code files, and in some cases, binary files.

Document generation can be divided in several type of documents:

• Batch documents (all automated documents)
• Interactive documents (documents that can not be produced automatically)
• Text block correspondence (documents created based on pre defined text blocks)
• Forms (forms for websites)

You can place every type of document you come across in one of these categories. A lot of software solutions are offered on the internet that can automate these processes.

[edit]See also

• Comparison of documentation generators
• Template processor
• Static code analysis
• Literate programming

From Wikipedia, the free encyclopedia

Javadoc is a documentation generator from Sun Microsystems for generating API documentation in HTML format from Java source code.

The “doc comments” format used by Javadoc is the de facto industry standard for documenting Java classes. Some IDEs ^[1], such as Netbeans and Eclipse will automatically generate Javadoc HTML. Many file editors will assist the user in producing Javadoc source and will use the Javadoc info as internal references for the programmer.

Javadoc also provides an API for creating doclets and taglets, which allows you to analyze the structure of a Java application. This is how JDiff can generate reports of what changed between two versions of an API.

[edit]Structure of a Javadoc comment

A Javadoc comment is set off from code by standard multi-line comment tags /* and */. The opening tag, however, has an extra asterisk, as in /**. The first paragraph is a description of the method documented. Following the description are a varying number of descriptive tags, signifying the parameters of the method (@param), what the method returns (@return), any exceptions the method may throw (@throws), and other less-common tags such as @see (a “see also” tag).

[edit]Example

An example of using Javadoc to document a method follows. Notice that spacing and quantity of characters in this example are as conventions state.

/**
 * Validates a chess move. Use {@link #doMove(int, int, int, int)} to move a piece.
 *
 * @param theFromFile file from which a piece is being moved
 * @param theFromRank rank from which a piece is being moved
 * @param theToFile   file to which a piece is being moved
 * @param theToRank   rank to which a piece is being moved
 * @return            true if the chess move is valid, otherwise false
 */
boolean isValidMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
{
    ...
}

/**
 * Move a chess piece.
 *
 * @see java.math.RoundingMode
 */
boolean doMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
{
    ...
}

[edit]Criticism

The pages generated by Sun’s Javadoc are static HTML pages utilizing frames, rather than using more modern, dynamic techniques. Pages do not include a built-in search function.

Cuando agregamos librerías opcionales del JDK al mismo, por ejemplo Comm API o JAI, notaremos que sus clases se encontrarán disponibles automáticamente para utilizar dentro del IDE, pero no conseguiremos poder ver su Javadoc.

Para poder indicarle a NB donde se encuentra la Javadoc a cargar tenemos que ir al menú Tools->Java Platforms:

Tools->Java Platforms

Luego, dentro del diálogo “Java Platform Manager” elegimos la versión de JDK que utilizamos (si tubieramos varios configurados), vamos a la pestaña “Javadoc” y agregamos la ruta al archivo por medio del selector de archivos que aparece al hacer click en “Add ZIP/Folder…”

Diálogo Java Platform Manager

Cerramos el dialogo haciendo click en “Close”

Finalmente probamos que se puede visualizar la Javadoc correctamente

Comprobando Javadoc

Saludos

The last week of OJT feels relaxed for now, and since we’re done with the actual program, it’s time to make the manuals and documentation. Now, our system is coded in Java, and Java programs will naturally have to have their Javadocs. Here at Azeus, we use Eclipse (like most of us do at school). All summer, my “love” for Eclipse has been nothing but increasing. One especially useful shortcut for documenting code is alt+shift+j, which generates Javadoc comments for the selected method/component. It lists all parameters and the “@return” code, all you have to do is fill in some information. Another handy shortcut is ctrl+shift+f, which automatically formats your code (doesn’t seem to work for .jsp files though, shame). All uber-long lines of code will be split and properly indented, making code stuff much less painful to read.

–Leslie

Class-level Comments

Class-level comments provide a description of the class, and they are placed right above the code that declares the class. Class-level comments generally contain author tags, and a description of the class. An example class-level comment is below:

/**
 * @author Sarah Smith
 *
 * The Inventory class contains the amounts of all the
 * inventory in the CoffeeMaker system.  The types of
 * inventory in the system include coffee, milk, sugar
 * and chocolate.
 */
public class Inventory {

   //Inventory code here

}

Member-level Comments

Member-level comments describe the fields, methods, and constructors. Method and constructor comments may contain tags that describe the parameters of the method. Method comments may also contain return tags. An example of these member-level comments are below:

Javadoc Tags

To add a class hyperlink, we have to add a tag in the comment. The format of class hyperlink tag is:

{@link <FullClassName> [Display Text]}

FullClassName is the name of the class you wish to link to. The class name must also include the package name if the target class is not in the same package. Display Text is optional. It is the text that will be displayed in the document. If the display text is ignored, the result document will display the full class name.

 To add a hyper link to a method of the same class, we use the @link tag like this:

{@link #<MethodSignature> [Display Text]}

MethodSignature is the signature of the target method, including the method name and the parameter types.

Note: It’s sometimes difficult to type the right method signature. You may simply type # and some beginning characters of the method name, press Ctrl-SPACE, and a list of the method signatures that match will pop up. You can select a method from the list.

To add a hyper link to a method in a different class, we use the @link tag like this:

{@link <ClassName>#<MethodSignature> [Dsplay Option]}

ClassName is the full name of the class where the method resides. It must include the package name if the class is not in the same package. MethodSignature is the the method signature where this comment links to. If Display Option is not specified, the name of the class and method will be displayed in the document.

Note: Also, you can use Ctrl-SPACE to assist you typing.

The most common Javadoc tags are:

• @author: Describes the author of the document. Used in class-level comments
• @param: Describes a parameter of a method or constructor.
• @return: Describes the return type of a method.
• @throws: Describes an exception a method may throw.
• @exception: Describes an exception.

Para un desarrollador, disponer de un entorno de desarrollo o IDE es básico para poder aumentar su productividad y poder trabajar de forma rápida y tranquila. Ya tratamos Aptana en este articulo donde explicabamos paso a paso su instalación.

Por ello hoy os vamos a presentar Aptana Studio, un IDE para la programación de aplicaciones web dinámicas, con especial soporte para Ajax/JavaScript.

Aptana Studio es un entorno de desarrollo basado en Eclipse que soporte para HTML, DOM, JavaScript y CSS, así como soporte para plataformas emergentes que utilizan Ajax como Adobe AIR e iPhone.

Si estás acostumbrado a Eclipse, te será facilísimo acostumbrarte a su uso, en caso contrario verás que es bastante sencillo y sobretodo completísimo.

Además Aptana Studio puede extender sus funcionalidades a base de plugins para trabajar más comodamente con algunos lenguajes de programación como PHP, Python o Ruby on Rails.

Aptana Studio es totalmente gratuito y funciona en plataformas Windows de 32 o 64 bits, Mac OSX 10.4 o superior, en Linux de 32 bits con GTK o en Linux de 64 bits como plugin dentro de Eclipse.

Podemos descargar este fantástico entorno desde este enlace a la página oficial de Aptana.

This book aims serving students, developers, technical leads and to some extent project managers or consultants by demonstrating a structured documented modestly sized project.

Learning the project development and documentation is done through the construction of an Online Shopping Cart [integrated with a payment gateway] using MySQL Community Server as the data store with Java Server Pages as the delivery mechanism, Struts 2 as the framework and Hibernate 3 as the Object Relational Mapping library.

Framework migration [Struts 2.0.x to 2.1.x] and the art of migrating the application across databases [with the help of Hibernate] is what the readers would definitely appreciate.

ISBN 10: 81-8404-696-0

ISBN 13: 978-81-8404-696-0

Edition: First

Downloads

Sample Chapter TOC

THE TOPICS COVERED IN THE BOOK

Understanding The Framework

Setting Up The Environment

About The Project

Software Design Documentation

End User Manual

Running The Project

Process Flow

Migration

Appendix

THE LEARNING THAT TAKES PLACE

Shopping cart

Google checkout

Tag clouds

Session management

Directory

Search

Sending emails

Files in BLOB

Validations

JavaDoc

Data Access Object design pattern

Access based user management

Hibernate based pagination

Restricted page access protection

User authentication interceptor

Custom error pages

Double form submission prevention

Application migration from Struts 2.0.x to 2.1.x

Database migration from MySQL to Oracle

CONTENTS OF THE CD-ROM

Setup files for JDK 6

MySQL Community Server 6

MySQL Connector/J

Oracle Database 10g XE

Oracle JDBC

Struts 2.0.x

Struts 2.1.x

Hibernate 3

Source code for the project [for Struts 2.0.x and Struts 2.1.x]

SQL Import Scripts for MySQL and Oracle

Elegant MicroWeb to build Liferay compatible, ecommerce shopping cart tool for a leading online media advertising agency in USA

Elegant MicroWeb is pleased to announce that it has been selected to build a software tool for online ecommerce shopping cart for a reputed online media advertising agency in USA. The tool will have well researched intuitive and intelligent SEO friendly user interface with searchable product catalogue, shopping cart, payment gateway integration and order processing. The tool is multi vendor tool, supporting more than one vendors with multiple product catalogues, and has secured interface both for vendor administrators as well as super administrator.

The tool will be based on industry standard, scalable architecture with JBoss application server and will have JSR286 compliant portlets with LIferay 5.2.3 CMS framework compatibility. Application development framework would be JSF, JBoss Seam, JPA and Icefaces facelets.