Classpath-based optional compilation (Re: New TagLib, votes please)

[Jeff Turner <je...@socialchange.net.au>]

On Mon, 30 Oct 2000, Jeremy Quinn wrote:
> So, let's try again ....
> 
> Option 1
> 	Install as is, including two new Sun JARs in the distribution.
> 
> Option 2
> 	Provide as a standalone in the contrib directory
> 
> Option 3
> 	Put all code in the LogicSheet, so JARs only required if someone runs it.
> 
> Option 4
> 	Install as in Option 1, without Sun's JARs, using Ant to conditionally
> compile.

Just wondering.. does this optional compilation based on the contents of a
CLASSPATH variable seem a bit.. wrong?

IMHO it would be nicer is there was an explicit flag for each optional
component.

Using the presence of a class in the classpath as an implied flag is
pretty non-intuitive. As a consequence, it's very easy to forget.
Remember when Robin Green was creating the 1.8 distribution, and left out
some xt classes? IMHO, that's a symptom. It's happened to me too, many
times, and I'm sure lots of other people.

What happens when the builder wants some optional modules, but does not
have the requisite jars at hand. Who's to say the build environment is the
same as the deploy environment? Frequently it's not.

Classpaths are inherently evil anyway. Java doesn't allow access to any
other environment variables, for the good reason that many systems (like
Macs) don't have them. To quote from the Java FAQ:

 "It was a design error in JDK 1.0 that programmers had to set the
CLASSPATH environment variable. This should have been set in a property
file"
 -- http://java.sun.com/people/linden/faq_b2.html#I/O

How do people with Macs currently compile optional stuff into Cocoon?

So basically, I think it's wrong to tie Cocoon's build system to an
environment variable, and especially not for non-intuitive uses such as
flagging the inclusion of optional components.

But then I'm frequently wrong ;)

--Jeff

> 
> Back to you Ladies and Gentlemen.
> 
> regards Jeremy
> -- 
>    ___________________________________________________________________
> 
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
> 
>    <ma...@mac.com>     		 <http://www.media.demon.co.uk>
>     <phone:+44.[0].20.7737.6831>        <pa...@sms.genie.co.uk>
> 

Re: Classpath-based optional compilation (Re: New TagLib, votes please)

[Jeff Turner <je...@socialchange.net.au>]

On 31 Oct 2000, Brian May wrote:

> >>>>> "Jeff" == Jeff Turner <je...@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 <ba...@snoopy.apana.org.au>
> 

Re: Classpath-based optional compilation (Re: New TagLib, votes please)

[Brian May <ba...@snoopy.apana.org.au>]

>>>>> "Jeff" == Jeff Turner <je...@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.

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...
-- 
Brian May <ba...@snoopy.apana.org.au>