Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-dev@jakarta.apache.org>
Subject: RE: Problems with the current bootstrap process
Date: Tue, 30 Jan 2001 14:24:57 +1100
Message-ID: <NDBBIMHCHMPELMBMMFIMCEGHFBAA.conor@cortexebusiness.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3.0.6.32.20010130131346.00a67430@alphalink.com.au>

> From: Peter Donald [mailto:donaldp@apache.org]
>
> At 12:43  30/1/01 +1100, Conor MacNeill wrote:
> >> >
> >> >Huh? If we can't get the version from an embedded properties
> resource we
> >> >won't have much chance to load the task list either.
> >>
> >> correct.
> >
> >So you are saying ant should not use resources. I don't agree.
>
> No I am saying that it should not be required that resources are used.
> Especially in cases like this when there is a simple alternative that does
> the exact same thing.
>

So you are only solving half the issue. Is that right?

> >because it is data - not code.
>
> Yes - compile time static data

Well, I guess I don't see version information as compile-time static data.
Is there some code which depends on the value of the version information at
compile time? The fact that you need to copy and munge the code is perhaps
indicative of the problems with this approach.

> There is a reason that this is a time
> houred practice in creating a dll/so files ;)

We are not building DLLs and it seems to me that the Java way is to use
resources. Some examples: For example the JAXP RI, Xerces, Xalan all use
resources (properties files and other types) in their jars.


> While the argument could be
> made that java resources are equivelent to "resources" in a win32 app and
> thus acceptable.

Yep.

> However resources ala win32 are different as there are
> compile time checks that will stop compilation (at least in VC6) if you
> screw up the win32-resources mapping.
>

I don't know much about Win32 resources but IIRC, version resources on a Mac
have no compile time checks. Not sure how relevant this point is.

> >because changing it is not backward compatible
>
> true - but the chances of someone actually using this are minimal that I
> think it is acceptable.

Probably right. This implies that there are levels of backward compatibility
we are prepared to break.

Conor