Stefano Mazzocchi wrote, On 25/02/2003 17.22:
Carsten Ziegeler wrote:
One solution to avoid filtering our java-code because of jdk-dependencies
is to separate this code into different source directories.
For example for the databases block that uses ant filtering we could
generate three directories:
blocks/databases/java - the common code
blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK 1.2/1.3
blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4 and
above
This is then similar to our libs directory.
This solution would not only remove the need of filtering but would also make the source directly usable within your favorite IDE.
What do you think?
big +1!
I kinda like the idea, but why not
blocks/databases/java/org/apache/xxx blocks/databases/java/org/apache/xxx/1.2 blocks/databases/java/org/apache/xxx/1.4
?
And how can one use them within the favourite ide?
The code filtering problem is suggesting me that preprocessing source code is a very bad habit and we should try to avoid it alltogether!
;-)
I have been working on a build system for quite some time too, and my opinion is that... I don't have an opinion! ;-)
Filtering is a "hack" to overcome javac and java deficiencies with some sort of preprocessing. Think about instrumenting code, using altrmi statically, or using aspects. Filtering here is needed.
It's just a tool, use it only when it's really needed. In this case it's not so needed, so this solution seems optimal :-)
That should turn Constants.java in a property file that Cocoon reads out of its own jar file when it starts.
Yes!
So both Cocoon and the build system can read it! One source! :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------