ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Patternsets, Filesets, and Mapper
Date Wed, 27 Feb 2002 20:59:04 GMT
> Yikes, I didn't realize I was still in this discussion!  :)

Sorry, but at the time, you two were the only ones that had responded.

> There is a package Mapper that I created that is available too.  I'm not
> sure if that would be of help here, as you'd have to add support for mappers
> to <javadoc>, but it converts file paths to dotted package names.  I used it
> for <uptodate> checks from test cases to their <junit> XML results (which
> are filenames in a flat directory with package name in the filename).  Does
> that help this situation any?

Yeah, I know. I actually put this comment in my mappers:
" * Design gleaned from the PackageNameMapper by Erik Hatcher."

Basically, I created two mappers that do just the opposite of yours. Where yours will take
a filename and convert it into a package name, mine takes a package name and convert it
into a ".java" or ".class" filename.

By putting the mapper into the PatternSet (and the FileSet createMapper just calls it on
the default patternset like the rest of the methods), any method that normally takes a
PatternSet or FileSet could take a list of package names.

Realistically, I am sure that there has to be a solution with the current codebase... but,
I have not (through the API, Manual, or emails) been able to replicate the simple tool we
have internally.  With the internal tool, we maintain one list of package names for each
project, converting to .java or .class, or even figuring out that are in the
classes directory, etc... But, as of yet, it seems I have to maintain multiple lists of
the same files to use vanilla ant without my patches.  I have come up with other ways in
which I could do it, but they don't seem as clean -- ie: if the mapping conversion has to
happen in every task that needs the files, we have to cut-n-paste a section of code into
multiple source files instead of providing it in one place where they all immediately gain
the capabilities.

I am not fighting for the previously-submitted patch to remain; it was written to fix a
problem that I couldn't find a solution to.  What I am trying to do is understand the
philosophy behind the design so that I can patch it correctly.

I could just do an Exec of my previous build tool, but then it seems kinda pointless to be
using Ant at all.  I would rather fix Ant to provide the additional behavior for any who
would like to use it.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message