(ccing to cocoondev to see if they like the idea) (ccing to krysalis-dev because it seems like the solution to the jdk filtering stuff)
didge wrote, On 24/02/2003 22.23:
But the 'lost-update' issue is a much more serious one. Dead serious, I might say, the problem is that the way the javac task is designed (again, it could well be my fault since I enhanced that task a lot in the past) is that is path based.
The problem is not with the <javac> task, it is with JavaTM itself. I've said it on this list before, I know, but I just can't stop myself...
<soapbox> JavaTM <em>needs</em> an integrated preprocessor. Without anyway to instruct IDEs (such as with a #line directive), IDEs simply cannot distinguish between the preprocessed and source files, leaving developers to figure it out themselves. </soapbox>
This is IMHO a *very* good point. If I see a .java file, I assume that I can compile it with javac, but with filtering it's not the case! I agree with you.
...
1. Any file that needs preprocessing gets a .java.vpp extension. 2. Preprocess all files with the .java.vpp extension sending output to an gen directory _not_ in your regular source directory. 3. Compile everything normally, including the gen directory as an additional src path.
Using the extension both identifies the file as needing preprocessing and also prevents it from being compiled directly.
Yes. And also makes it automatic. I mean that we son't need to copy *all* files, or select them one by one by hand. Simple, clean effective. I like it :-)
Oh, and how about "stale" files. I mean, if I vppcopy a file, then delete the original vpp, is the filtered resulting java file still there? IIRC there was a lsync task floating around that synched correctly, maybe a vppsynch could be the *final* solution?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------