javadoc

In Java if you package the source code ( .java) files into the jar along with classes ( .class) most IDE's like eclipse will show the javadoc comments for code completion. IIRC there are few open-source projects that do this like JMock. Lets say I have cleanly separated my API code from implementation code so that I have something like myproject-api.jar and myproject-impl.jar is there any reason why I should not put the source code in my myproject-api.jar ? Because of Performance? Size? Why don't other projects do this? EDIT: Other than the Maven download problem will it hurt anything to put

I need to exclude specific source files (NOT just packages) from Javadoc using Maven. The <excludePackageNames> setting will not work for me: it only allows you to exclude certain packages. There's a <sourceFileExcludes> setting that has basically no documentation in the way of usage examples. It just says: "sourceFileExcludes: exclude filters on the source files. These are ignored if you specify subpackages or subpackage excludes." So, basically, I need to ignore all Java files that start with Mock, and also all Java files in two packages. Since sourceFileExcludes are ignored if I specify

I have an inner class which declares a constant and want to display its value in Javadoc of the enclosing top-level class using the @value annotation. For example: /** * {@value #FOO_CONS} // this displays well * {@value #BAR_CONS} // this does not work (checked in the latest Eclipse) * {@value Bar#BAR_CONS} // this does not work, either */ public Foo { public static final int FOO_CONS = 1; static class Bar { public static final int BAR_CONS = 42; } } Any ideas how to display the value of BAR_CONS in Javadoc of the Foo class (or any other class, in general)? Javadoc format for constant defined

I was wondering. Do any of you have a JavaDoc style sheet? The default one is pretty ugly. Thanks! Supertux Red and black one here: http://blog.applegrew.com/2008/05/get-my-javadoc-stylesheet-red-n-black-theme/ You also might want to take a look at doclet.com . You can try Javadoc-Themer which allows you to generate your own stylesheets with selected colors. The code is open sourced on github . P.S: I am the developer of Javadoc-Themer Web app can be found here Just wanted to add it here for completeness: Kenai's stylesheet is public domain: http://kenai.com/projects/help/forums/features

Consider a static method in a class, which I have documented it using javadoc : /** * Description here. * * @param names - The parameters of the impression request. * @param ids - An intent object to enrich. * @param prefix - A prefix. */ public static void parse(Map<String, String> names, String ids, String prefix) ... In order to avoid duplicating the description in the overloaded versions of the method, I would like to use a javadoc @link : /** * Overloaded version with default prefix. * {@link #<parse(Map<String, String>, String, String)> [Text]} */ public static void parse(Map<String,

I'm trying to add package level annotations but I don't have a clue on how to do it. Examples are appreciated. Summary from the article here In package-info.java: @PackageLevelAnnotation package blammy; // package with a package level annotation. import blammy.annotation.PackageLevelAnnotation; In PackageLevelAnnotation.java package blammy.annotation; @Retention(RetentionPolicy.CLASS) @Target(ElementType.PACKAGE) public @interface PackageLevelAnnotation { // stuff as required. } Edit: more package level info. Here is a link to the package chapter in the Java Language Spec: packages

Which is the more appropriate HTML tag for breaking up paragraphs/long sections of javadoc so according to best practices? Is it <p /> or <br /> ? Why? Welcome to the land of HTML 3.2. According to the official guide on writing doc comments, the correct way to separate paragraphs is with the paragraph tag: <P> . Take a look at the seventh bullet in the section on Format of a Doc Comment . Ordinarily, I would strongly recommend against using such old, outdated practices for markup. However, in this case, there's a decent reason to make an exception. The JavaDoc tool (unless radically updated