Jon Stevens wrote: > Please back that patch out and come up with a better solution.
Care to help define that better solution? :-) Originally, the code scanned all the .java files in *all* directories under sourcepath to see if they are java files, what package they came from, and if it matched one of the simple patterns provided by packagenames. It was horrendously slow. I submitted a patch to simply scan the directory structure, looking for .java files along the way, and matching directory names against the simple package patterns. This sped things up dramatically. It was accepted by the other commiters of the day. So yes, this is my fault. :-) I introduced a problem in that I'm assuming any .java files in the directory structure match the package name. 99% of the time, this is fine. There have been about 5 complaints concerning the fact that CVS stores (I believe, I probably have this wrong) original copies of the files in the CVS/Base directory during a cvs edit. The workaround is to copy the source tree to a clean location, and build the javadocs from there. And yes, I don't like it either. :-) So, how do I solve the problem? One solution is to create a packages element that looks something like <packages> <include name="org.apache.**" /> <exclude name="**/CVS/**" /> </packages> Now, that looks like crap, and doesn't actually address the issue. The exclude attribute, as used here, is a reflection of the directory structure, not the package structure. What I'm having problems with is how do I represent a package structure, while explicitly telling it to ignore *a directory structure*? The filesets get away with the include and exclude model, because they are all simply files and directories. Do I do something like <packages> <include name="org/apache/ant/**" /> <exclude name="**/CVS/**" /> </packages> I'm happy to back out the change and I'll do it now, but I'd like some input as to a better solution. Glenn McAllister
