cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: Classpath-based optional compilation (Re: New TagLib, votes please)
Date Tue, 31 Oct 2000 09:27:19 GMT


On 31 Oct 2000, Brian May wrote:

> >>>>> "Jeff" == Jeff Turner <jeff@socialchange.net.au> writes:
> 
>     Jeff>  "It was a design error in JDK 1.0 that programmers had to
>     Jeff> set the CLASSPATH environment variable. This should have
>     Jeff> been set in a property file" --
>     Jeff> http://java.sun.com/people/linden/faq_b2.html#I/O
> 
> I think the problem with CLASSPATH is:
> 
> a) it contains information specific to each computer. Where is Java
> installed? What version is installed? Or, perhaps several different
> versions of Java are installed on the one computer.  In this case,
> which one should be used? Same Java environments set the CLASSPATH for
> this case automatically, however, not all do.

Well at some stage this info has to be known. As a user of a system that
DOES have the notion of env variables, I'm glad they did use CLASSPATHs
instead of properties files.

> b) it contains information specific to each project.
> 
> So, the user typically has to manually setup the CLASSPATH for each
> project, with the system specific stuff. I don't think a properties
> file will help this...

Exactly :) This is why I really like the notion of self-contained
projects. Where I work, there's a rule that every Ant-based project must
compile with an empty CLASSPATH.

But to get back to the topic, tying the build process to the build
environment seems wrong to me. It doesn't matter whether that build
environment is set via a CLASSPATH or a properties file. Make the build
process depend on the build *options*, but not the build *environment*. 

--Jeff

> -- 
> Brian May <bam@snoopy.apana.org.au>
> 



Mime
View raw message