Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E5B9CAB.1070900@apache.org>
Date: Tue, 25 Feb 2003 17:41:15 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [Proposal] Splitting JDK dependent code  [was: Re: Javac task
 design problems]
References: <LKENJPKDAIKAPKHEOCMMAELPCMAA.cziegeler@s-und-n.de>
 <3E5B9841.3040507@apache.org>
In-Reply-To: <3E5B9841.3040507@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------