You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by sebb <se...@gmail.com> on 2013/07/26 12:52:56 UTC

EOL not being fixed in some resources; should not fix EOL at EOF

The EOL is not being correctly converted for the following files:

resources/css/*.css
resources/xsl/*.xsl
META-INF/NOTICE
META-INF/LICENSE
version.properties

I think that is handled in rc.gradle:CopySpec sources()
It looks like it should be sufficient to just add some extra includes
to the first section.

I also now think the filter should not attempt to fix EOL at EOF, i.e.
the filter should have setFixLast(false);
If the final EOL is missing in SVN, it should remain so in the archive.
I assume this would have to go into Line.groovy, but I've no idea how
to do that.

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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2013-07-26 at 14:09 +0100, sebb wrote:
> On 26 July 2013 14:04, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Fri, 2013-07-26 at 13:54 +0100, sebb wrote:
> >> On 26 July 2013 12:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> >> > On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
> >> >> The EOL is not being correctly converted for the following files:
> >> >>
> >> >> resources/css/*.css
> >> >> resources/xsl/*.xsl
> >> >> META-INF/NOTICE
> >> >> META-INF/LICENSE
> >> >> version.properties
> >> >>
> >> >
> >> > These are resources and I personally think they should not be meddled
> >> > with.
> >>
> >> It's not a question of meddling, it's a question of consistency.
> >> AFAIK these are all eol:native files so will be different in
> >> workspaces on hosts with different EOLs.
> >>
> >
> > The release script can't know that.
> 
> But it already does fix the EOLs for other text files, and it can be
> told to fix the files it currently skips.
> 

None of which is a resource.

Oleg



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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by sebb <se...@gmail.com>.
On 26 July 2013 14:04, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2013-07-26 at 13:54 +0100, sebb wrote:
>> On 26 July 2013 12:46, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
>> >> The EOL is not being correctly converted for the following files:
>> >>
>> >> resources/css/*.css
>> >> resources/xsl/*.xsl
>> >> META-INF/NOTICE
>> >> META-INF/LICENSE
>> >> version.properties
>> >>
>> >
>> > These are resources and I personally think they should not be meddled
>> > with.
>>
>> It's not a question of meddling, it's a question of consistency.
>> AFAIK these are all eol:native files so will be different in
>> workspaces on hosts with different EOLs.
>>
>
> The release script can't know that.

But it already does fix the EOLs for other text files, and it can be
told to fix the files it currently skips.

It's not a question of making the release script sensitive to the
local EOL setting; it just needs to create the same source archive
contents whether it runs on Unix or Windows.

> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2013-07-26 at 13:54 +0100, sebb wrote:
> On 26 July 2013 12:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
> >> The EOL is not being correctly converted for the following files:
> >>
> >> resources/css/*.css
> >> resources/xsl/*.xsl
> >> META-INF/NOTICE
> >> META-INF/LICENSE
> >> version.properties
> >>
> >
> > These are resources and I personally think they should not be meddled
> > with.
> 
> It's not a question of meddling, it's a question of consistency.
> AFAIK these are all eol:native files so will be different in
> workspaces on hosts with different EOLs.
> 

The release script can't know that.

Oleg



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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by Gary Gregory <ga...@gmail.com>.
On Jul 26, 2013, at 8:55, sebb <se...@gmail.com> wrote:

> On 26 July 2013 12:46, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
>>> The EOL is not being correctly converted for the following files:
>>>
>>> resources/css/*.css
>>> resources/xsl/*.xsl
>>> META-INF/NOTICE
>>> META-INF/LICENSE
>>> version.properties
>>
>> These are resources and I personally think they should not be meddled
>> with.
>
> It's not a question of meddling, it's a question of consistency.

I like consistency.
:)
Gary
> AFAIK these are all eol:native files so will be different in
> workspaces on hosts with different EOLs.
>
> If the source archives are created on Unix, they currently have
> Eol=LF, however on Windows they will have Eol=CRLF.
>
> If the files are supposed only ever to have EOL=LF, then the eol-style
> needs to be changed.
>
>>> I think that is handled in rc.gradle:CopySpec sources()
>>> It looks like it should be sufficient to just add some extra includes
>>> to the first section.
>>>
>>> I also now think the filter should not attempt to fix EOL at EOF, i.e.
>>> the filter should have setFixLast(false);
>>> If the final EOL is missing in SVN, it should remain so in the archive.
>>> I assume this would have to go into Line.groovy, but I've no idea how
>>> to do that.
>>
>> I adjusted the parameter map passed to the filter. Last line fix is now
>> set to false.
>
> Thanks.
>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by sebb <se...@gmail.com>.
On 26 July 2013 12:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
>> The EOL is not being correctly converted for the following files:
>>
>> resources/css/*.css
>> resources/xsl/*.xsl
>> META-INF/NOTICE
>> META-INF/LICENSE
>> version.properties
>>
>
> These are resources and I personally think they should not be meddled
> with.

It's not a question of meddling, it's a question of consistency.
AFAIK these are all eol:native files so will be different in
workspaces on hosts with different EOLs.

If the source archives are created on Unix, they currently have
Eol=LF, however on Windows they will have Eol=CRLF.

If the files are supposed only ever to have EOL=LF, then the eol-style
needs to be changed.

>> I think that is handled in rc.gradle:CopySpec sources()
>> It looks like it should be sufficient to just add some extra includes
>> to the first section.
>>
>> I also now think the filter should not attempt to fix EOL at EOF, i.e.
>> the filter should have setFixLast(false);
>> If the final EOL is missing in SVN, it should remain so in the archive.
>> I assume this would have to go into Line.groovy, but I've no idea how
>> to do that.
>>
>
> I adjusted the parameter map passed to the filter. Last line fix is now
> set to false.

Thanks.

> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Re: EOL not being fixed in some resources; should not fix EOL at EOF

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2013-07-26 at 11:52 +0100, sebb wrote:
> The EOL is not being correctly converted for the following files:
> 
> resources/css/*.css
> resources/xsl/*.xsl
> META-INF/NOTICE
> META-INF/LICENSE
> version.properties
> 

These are resources and I personally think they should not be meddled
with.

> I think that is handled in rc.gradle:CopySpec sources()
> It looks like it should be sufficient to just add some extra includes
> to the first section.
> 
> I also now think the filter should not attempt to fix EOL at EOF, i.e.
> the filter should have setFixLast(false);
> If the final EOL is missing in SVN, it should remain so in the archive.
> I assume this would have to go into Line.groovy, but I've no idea how
> to do that.
> 

I adjusted the parameter map passed to the filter. Last line fix is now
set to false.

Oleg 



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