ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Hatton" <>
Subject RE: Javac: multiple source roots & filesets
Date Wed, 26 Apr 2006 15:51:58 GMT
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

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.


-----Original Message-----
From: Wildish, Joe STASCO-OTO/72 [] 
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.


-----Original Message-----
From: Steve Loughran []
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/ root_b/ root_b/
> javac handles this OK (ie. it is not privy to root_a/, 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 

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 
  -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.


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

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

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

View raw message