ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <levylamb...@tiscali-dsl.de>
Subject Re: cvs commit: jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs JarTest.java
Date Mon, 27 Jan 2003 14:38:42 GMT
I would go for using forward slashes :
     - maybe convert to forward slashes immediately in the constructors of
Resource and in Resource#setName
     - then one would need to pay attention when one wants to find the
corresponding file on a Windows filesystem
You are right that the current solution smells a bit, I have the impression
that I am rebuilding all my ant jars every time I do a build.
Antoine
----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Monday, January 27, 2003 3:09 PM
Subject: Re: cvs commit:
jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs JarTest.java


> On 27 Jan 2003, <bodewig@apache.org> wrote:
>
> >   ZIP-Entries always use forward slashes
>
> I'm not sure that this is the best solution to the problem.
>
> The context is:
>
> SourceSelector calls getResource on ResourceFactory with a name
> argument that comes from a Resource#getName.  As it stands we have two
> different Resource types, but there may be more in the future.
>
> File base Resources will hand out Resources with names that will have
> platform specific file separators.  They probably expect names in
> getResource calls to use the platform's separator, but may be able to
> deal with forward slashes even on Windows.
>
> ZipEntry based Resources will hand out Resources with names that
> always use / as separator, they can now deal with both types of input.
>
> Maybe it would be better to tighten up the contract, both for
> Resource#getName as well as ResourceFactory#getResource?
>
> What would be the best policy?  Use the platform's separator
> everywhere?  Use slashes everywhere?  Accept everything but always
> return the platform dependent names?  I'm not sure, but the current
> solution smells a bit.
>
> Stefan
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message