This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 123691 - -exclude package1:package2 option does not work
Summary: -exclude package1:package2 option does not work
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-08 20:04 UTC by lordpixel
Modified: 2009-11-02 11:03 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lordpixel 2007-12-08 20:04:50 UTC
I have a project with some packages I don't want to include in the JavaDoc output. Specifically they contain sample code.

I've tried passing -exclude my.samplecode.package in the additional command line options for JavaDoc in Netbeans, but it
still generates the documentation.

Now, I know I can use Include/Exclude on the 'Source Files' settings to exclude things from JavaDoc, but unfortunately
this also excludes them from being compiled etc.

I need a way to specify certain packages should not be documented.
Comment 1 Jan Pokorsky 2007-12-10 11:02:08 UTC
I guess the reason is that whatever nested fileset of the javadoc ant task overrides javadoc's -exlude option. This
should be resolved in org/netbeans/modules/java/j2seproject/resources/build-impl.xsl. Reassigning to java/j2seproject.

As a quick workaround you could write an own javadoc task in your <project-path>/build.xml e.g. as

    <target depends="init" name="-javadoc-build">
        <mkdir dir="${dist.javadoc.dir}"/>
        <javadoc sourcepath="${src.dir}" additionalparam="${javadoc.additionalparam}" author="${javadoc.author}"
charset="UTF-8" destdir="${dist.javadoc.dir}" docencoding="UTF-8" encoding="${javadoc.encoding.used}" failonerror="true"
noindex="${javadoc.noindex}" nonavbar="${javadoc.nonavbar}" notree="${javadoc.notree}" private="${javadoc.private}"
source="${javac.source}" splitindex="${javadoc.splitindex}" use="${javadoc.use}" useexternalfile="true"
version="${javadoc.version}" windowtitle="${javadoc.windowtitle}">
            <classpath>
                <path path="${javac.classpath}"/>
            </classpath>
            <!--fileset dir="${src.dir}" excludes="${excludes}" includes="${includes}">
                <filename name="**/*.java"/>
            </fileset-->
        </javadoc>
    </target>

that will take javadoc -exclude from javadoc additional options but ignores project -exclude.
Comment 2 lordpixel 2007-12-10 19:55:35 UTC
Thanks. I ended up making 2 separate projects.

Thinking about it, maybe I could have created 2 different configurations (Compile & Test vs. JavaDoc) within my project
with separate exclude/include lists for each one. Then I could flip to the JavaDoc configuration. I didn't actually try
that but logically it should work.

Best would be to fix the JavaDoc task somehow so as to merge the two exclude lists, but then that might be an ant bug...
Comment 3 Tomas Zezula 2008-02-29 11:08:19 UTC
No easy way how to do it in Ant. Javadoc task will need to merge the fileset with --exclude from additional args.
Maybe adding special exclude list into the javadoc options by default set to the project excludes which the user can change will help. 
Comment 4 Jan Becicka 2008-11-13 15:35:33 UTC
Will resolve later
Comment 5 lordpixel 2008-11-20 22:38:08 UTC
Setting a ticket to Resolved LATER just means no one will ever find it again because no one is going to be looking for
Resolved bugs.

In other words, it isn't going to be fixed, right?
Comment 6 Petr Dvorak 2008-11-20 23:24:26 UTC
"Resolved>Later" can be understood as "not planned to be fixed in this nor in the next release"...

http://wiki.netbeans.org/IssueLifeCycle#section-IssueLifeCycle-EvaluatingIssues

This issue state (LATER) was newly introduced since 6.5 to help us achieve better granularity of issue's "real
priority". We didn't use it before.

Simply and straight forward: issue that is "resolved>later" has absolutely the same chance to be fixed as it had before,
but now it is explicitly reflected in its status (which is IMO more fair/honest to users)...
Comment 7 lordpixel 2008-11-21 15:25:01 UTC
OK - I should have read your process document.

They stopped using this status on Firefox years ago because it became a dumping ground for stuff people didn't want to
think about.

But just because you use the same bug tracking tool (more or less) I shouldn't have assumed you use the same process.

Apologies.
Comment 8 Quality Engineering 2009-11-02 11:03:48 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX