[lang] CRLF handling in the release

[Henri Yandell <ba...@generationjava.com>]

The binary build now adds proper crlf handling for Windows zip for .txt
files [ie LICENSE and RELEASE-NOTES].

How much of the source distribution should be crlf'd? I'm thinking that'll
have to be all of it. .java, .txt, .xml, .html, .properties. Any reason
not to do this?

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] CRLF handling in the release

[Stephen Colebourne <sc...@btopenworld.com>]

I can't think of any, but I'm no build expert.

Stephen

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, August 17, 2003 8:56 PM
Subject: [lang] CRLF handling in the release


>
> The binary build now adds proper crlf handling for Windows zip for .txt
> files [ie LICENSE and RELEASE-NOTES].
>
> How much of the source distribution should be crlf'd? I'm thinking that'll
> have to be all of it. .java, .txt, .xml, .html, .properties. Any reason
> not to do this?
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] CRLF handling in the release

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Henri!

It's a bit late comment, don't know if you've done
it already or not (harvesting long overdue piles of mail)

HY> The binary build now adds proper crlf handling for Windows zip for .txt
HY> files [ie LICENSE and RELEASE-NOTES].

HY> How much of the source distribution should be crlf'd? I'm thinking that'll
HY> have to be all of it. .java, .txt, .xml, .html, .properties. Any reason
HY> not to do this?

Hmm.. I beleive that

1)

a good thing about pure Java code is that the release
is not really different for Windows and *nix.

I have always just grabbed the kind of release I liked more
(was more convinient to unpack, smaller, etc.) and pooled it
to whichever platform I needed. And it worked.

It just does not make sense to introduce platform dependence
when there by nature is none: with pure java code. Why have
two _different_ releases when we can have one?

2)

it looks a bit slippery path to me to differ the platform the
build is for by the method of archiving it. Why not to use
.tgz or .zip only as a method of packing? Why does the archiver
used mark the OS the distribution is targeted to?

I do have zip and unzip on my Linux. I do have tar, gzip and
bzip2 on windows box. I can use any I like.

3)

So, is it really possible to use binarily equivalent releases
for both *nix and Windows? Does it bring any drawbacks?
0x0D looks quite portable to me. I would say that there are
more editors will that will display 0x0D-ed text correctly then
those that will dispay 0x0D 0x0A-ed text. In fact the only
editor I know that has issues with 0x0D is Notepad.

Gentelmen, did I succed in presenting _some_ argumentation
for keeping all 0x0D?  Just my idle thoughts :-)

Anton

Re: [lang] CRLF handling in the release

[Stephen Colebourne <sc...@btopenworld.com>]

I can't think of any, but I'm no build expert.

Stephen

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, August 17, 2003 8:56 PM
Subject: [lang] CRLF handling in the release


>
> The binary build now adds proper crlf handling for Windows zip for .txt
> files [ie LICENSE and RELEASE-NOTES].
>
> How much of the source distribution should be crlf'd? I'm thinking that'll
> have to be all of it. .java, .txt, .xml, .html, .properties. Any reason
> not to do this?
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>