> 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 _Stub.java 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. Malachi -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
