Hi Keith, I've ended up going down route 1. Seems easiest to explain, and as I won't be maintaining these personally, going forward, that's pretty important.
Cheers, Jo -----Original Message----- From: Keith Hatton [mailto:[EMAIL PROTECTED] Sent: 26 April 2006 16:52 To: Ant Users List Subject: RE: Javac: multiple source roots & filesets Two possibilities that spring to mind: 1. <copy> the files you require from either source tree to a single working directory structure, then <javac> from there. 2. <delete> the generated files you don't want before invoking <javac>. As a general rule, I prefer introducing simplicity over hiding complexity, by which I mean that disambiguating the directory structure in some way prior to compilation is preferable to relying on quasi-arbitrary implementation details of the tools to ignore certain files. It seems that there ought to be a simpler way to achieve your desired result. Of course, in practice this depends on the complexity of your real project and the flexibility of your build process. Keith -----Original Message----- From: Wildish, Joe STASCO-OTO/72 [mailto:[EMAIL PROTECTED] Sent: 26 April 2006 13:38 To: Ant Users List Subject: RE: Javac: multiple source roots & filesets javac (command-line) can easily be forced to be privy to whatever you so wish it to be. IIRC the default sourcepath is your working directory. javac will use that to look-up any source files it needs for any implicit compilation it deems necessary. If the sourcepath is suppressed by issuing 'sourcepath ""', it forces javac to ONLY be aware of the source files you tell it about (including for any implicit compiliations that occur as a result of dependencies). It would be nice to be able to achieve this using specific filesets for each specified source directory in the <javac> task. FYI I am having to do this because of some auto code generation. At the beginning of development, you generate a skeleton of source files. One of these is an empty implmentation class, which you then take away and, well, implement. At build time, I am generating the skeleton again (to ensure non-implementation Java files are correct), but then combining it with the real implementation class (this is the duplicated class). Not dangerous in my book. Regards, Joe -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: 26 April 2006 12:49 To: Ant Users List Subject: Re: Javac: multiple source roots & filesets Wildish, Joe STASCO-OTO/72 wrote: > java root_a/One.java root_b/Two.java root_b/Three.java > > javac handles this OK (ie. it is not privy to root_a/Two.java, so does > not attempt to compile it). Like I warned, this is not always the case java.exe will pull in any java files it sees fit to compile something, provided they are laid out in a proper hierarchy. This is why you dont need to specify the exact order to compile files. As sun say in the javac.html page "javac can silently compile source files not mentioned on the command line." That's why using the command line to selectively filter stuff is a bad thing. Even at the terminal prompt, you can get burned. >Is the javac task not simply mimicking this behaviour? In which case, I should be able to emulate this within a target...? > javac does other things like dependency checking, wrapping around other compilers and the like. you can always use <exec> to call javac if you want. Personally, I think what you are trying to do is dangerous. It looks like you're trying to have per-platform/per-release customisation by producing different .class files for different systems. There are better ways to do this that are cleaner and more manageable -use the SCM system and branch -use an interface/implementation pattern and compile different implementations -tease the file that changes out into its own location (or even separate JAR), so you just include what you want, instead of trying to exclude things. Now, if <src> doesnt let you support multiple fileset sources then that may be a defect we need to fix, but I dont think your use case is something to encourage. Sorry. -steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
