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.
running JHIndexer target twice(ofcourse on different helpsets) in same jvm produces lots of exceptions and the ant log nearly becomes around 22MB; this is already filed in suns issuzilla (is still in progress) see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4456380 there are some workarounds mentioned in the above bug...
Works fine for the NB build - we have a number of modules with helpsets and you can build them in one Ant command. If you have a problem you must provide complete steps to reproduce from scratch.
Created attachment 22003 [details] ant file to reproduce bug
doesn't work for me. i attached a zip file to reprocue this: extract to $netbeans-src directory and run the build file
Your sample works fine for me, under JDK 1.4, 1.5, and 1.6, with Ant 1.6.2 on Linux: Issue_58605$ ant Buildfile: build.xml reproduce: Created dir: /space/src/nb_all/Issue_58605/JavaHelpSearch2 Running JavaHelp search database indexer... Deleting directory /space/src/nb_all/Issue_58605/JavaHelpSearch2 Created dir: /space/src/nb_all/Issue_58605/JavaHelpSearch2 Running JavaHelp search database indexer... BUILD SUCCESSFUL Total time: 3 seconds You will probably need to track this down for yourself, since no one else seems to be affected; and if you find something wrong in sources for nbantext.jar, the JRE, or JavaHelp, submit a patch to the appropriate owner with an explanation and a test case.
i am using jhall-2.0_01.jar when i switched to jhall-2.0_02.jar it is working fine... it might be bug in jhall-2.0_01.jar
OK.
i am able to reproduce this again .... copy jhall-2.0_02.jar to $ant_home/lib folder and run ant in $netbeans-src/Issue_58605 it was working for you, beacause ant was creating new class loader every time in you case. if you copy jhall-2.0_02.jar to $ant_home/lib then muliple instances of same classes are created and thus this issue gets reproduced...
Well don't do that then! It is bad style anyway to copy libs to JRE/lib/ext, JRE/lib/endorsed, or $ant.home/lib. Use <classpath> with <taskdef>.
> It is bad style anyway to copy libs to JRE/lib/ext, > JRE/lib/endorsed, or $ant.home/lib. Use <classpath> with <taskdef>. i know that. we are using xdoclet heavily on multiple large projects. our ant builds are running into outofmemory. on research i found that, there is some memory leask in ant, when each module does <typedef> for the same task. so we ended up coping those jars to ant/lib and using new ant1.6 namespace feature antlib:com.fiorano.ant so that we define a task only once. one day i will come up with steps to reproduce this, without copying libraries to ant/lib.
Sometimes you can just define the task in one place and let subprojects reuse it. We do this successfully in NB build scripts. If you can figure out a way to reproduce that does not involve Ant, NB, or anything besides JH and the JRE, I would encourage you to file a bug report on java.sun.com.