Re: Hack to ignore CVS directories.

[Jon Stevens <jo...@latchkey.com>]

on 1/22/01 9:05 AM, "glennm@apache.org" <gl...@apache.org> wrote:

> glennm      01/01/22 09:05:37
> 
> Modified:    src/main/org/apache/tools/ant/taskdefs Javadoc.java
> Log:
> Hack to ignore CVS directories.

-1.

I think that this should be done through the standard conventions (or a
centralized system) for looking up directories. CVS isn't the only system
out there that will have directories like that and we will continue hacking
this code as a result.

Please back that patch out and come up with a better solution.

-jon

-- 
Honk if you love peace and quiet.

RE: Hack to ignore CVS directories.

[Joshua Davis <js...@bellatlantic.net>]

I ran into the same problem last week.
If it's any help, the workaround I chose was:
- Use <copy> to copy all of the sources into a temporary directory.
- Run <javadoc> on the temporary directory.  Since <copy> automagically
filters CVS directories by default, javadoc didn't see them.
- <delete> the temporary directory.

Not pretty, but it works (and will continue to work as long as <copy>,
<javadoc> , and <delete> are upwardly compatible... heh-heh).

Re: Hack to ignore CVS directories.

[Jon Stevens <jo...@latchkey.com>]

on 1/22/01 12:37 PM, "Glenn McAllister" <gl...@somanetworks.com> wrote:

> Care to help define that better solution?  :-)

I thought I did.

> 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

There is already directory scanning code (or there used to be) that
autoexcludes a number of items such as "CVS, .cvsignore, etc..." Why can't
you use that?

I guess my point is and my complaint is that CVS is not going to be our only
revision control software (see: <http://subversion.tigris.org/>) and making
special cases for a directory called "CVS" all over the code is really bad
as when tools like Subversion are ready, you will now have "SVN" as a
directory name. 

It should be centralized somewhere. How you do the centralization is up to
you and this group to decide. :-)

-jon

-- 
Honk if you love peace and quiet.

Re: Hack to ignore CVS directories.

[Glenn McAllister <gl...@somanetworks.com>]

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