> I don't currently have the brain power to devote to this, but I'm having a > hard time understanding exactly how you are getting this list of packages > into Ant and in what format. Could you give us just a bit more detail on > your flow from command-line and text file format and such?
The main system is in C/C++, so (n)make is launching ant, passing in -D arguments for things like debug... There is a build.xml which handles javac, rmic, and javah. Then there is another xml (like javaobjex.xml) which handles creating all of the jars and docs for each sub-project. The current in-house tool uses an XML file and is being processed via JDOM and reflection to do the jar/javadoc -- but I am trying to switch this to Ant. > Perhaps some pre-processing XSLT is in order to generate your build file for > you? I am actually created the ant build files by hand right now. I am not so worried about the one time up-front time to make the files -- but can't figure out how they need to be done. The important thing is that we want to use Ant as a standardized way of doing the build instead of using loads of internally developed build tools. I want new employees to be able to step in and patch the build process, which is more difficult at the moment since no one else has touched the source to the current build tools. > I totally agree with you that Ant should natively deal with package names, > but I haven't thought through exactly how that should be done or at what > level... or if it even makes sense to consider for Ant 1.x. When is Ant 2.x slated for release? > It is frustrating that some things take package names (<test> inside > <junit>) wherease others take file paths - no argument there. > > This is my general thoughts as mentioned in a previous e-mail - Ant needs to > do an even better job of dealing with the Java "domain" such that we > construct our build files exactly as we *think* about our build processes. > It needs to be able to handle the package name <--> directory name > conversions natively at the appropriately places. It needs to be able to > pull a filename out of an absolute path where appropriate. We should not, > as build file writers, have to go through contortions to spell out simple > Java concepts. This is exactly what I was thinking. I am trying to convince management that this will be easier to maintain, but can't even figure out how to do it myself. > *blush* - why thank you! That, along with seeing the Java Tools book with > my name in it, at Barnes and Noble tonight have made my day! :) Really? Wow.... What's the title? > Still, putting a mapper inside these other datatypes is not quite right. > Perhaps the "mapper" concept inside a custom PatternSet subclass maybe? Yes, I sent a suggestion out earlier today that maybe I should subclass PatternSet to do a PackageSet... but, realistically, the NAME 'PatternSet' seems like it should work for both. Thanks all, Malachi -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
