cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task design problems]
Date Tue, 25 Feb 2003 16:41:15 GMT

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 for JDK 
>> 1.2/1.3
>> blocks/databases/java1.4 - the 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



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 in a property file that Cocoon reads out 
> of its own jar file when it starts.


So both Cocoon and the build system can read it! One source! :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message