10 a.m.
I'd like to propose that we change our Eclipse preferences (or the associated
preferences in whatever IDE you use) to force all created/edited files to be saved with
UTF-8 encoding and to use /n (LF) as the end-of-line delimiter. I'd also like to
convert all of the existing files in the DNA repository to use this encoding and
delimiter.
Currently the files in the DNA SVN repository contain a mixture of encoding formats and
end-of-line delimiters based upon the default behavior of the OS that was used to create
them. With regard to delimiters, Windows ends lines of text with \r\n (CR/LF), *nix with
\n (LF), and OS X with \r (CR). Eclipse apparently attempts to maintain the encoding and
delimiters used when the file was originally created, but other editors and file
manipulation tools don't. This sometimes results in multiple delimiter techniques used
within the same file.
One of the main problems with this situation is many tools can't handle this mixture
of encodings and/or delimiters. Git, for instance, relies upon \n only to determine what
constitutes a line. Thus, if you modify a single character in a git-managed file created
using OS X, then compare the file to the one in the repository, git will report the entire
file has changed. I've also seen problems in the past where someone inserts a
copyright symbol in a file header comment from Windows, and subsequent compilations fail
on a server performing continuous builds using Ant.
Given that we do standardize our encoding technique, I doubt anyone would object to the
ubiquitous UTF-8 standard. Regarding the delimiter, the two characters used by Windows
increases the size of each file needlessly and, considering DNA is a JBoss project,
Windows will probably be the least commonly used platform by developers. The OS X seems
inappropriate simply due to the number of tools that assume the existence of line-feeds.
I'd like to get everyone's feedback on this proposal. Since the second part of
this proposal probably involves modifying a large number of files in SVN, we'd
obviously want to do this sooner rather than later. Please comment when you get a chance.
Thanks,
John Verhaeg
Red Hat, Inc.
(314) 336-2950
10:12 a.m.
Considering that we already have files with every combination of line
delimiter (though thankfully each file is consistent), has anyone
experienced problems in your development environments? If so, please
speak up. I know Eclipse handles them well enough, and I suspect
other Java tools do as well. And for the most part I think the
operating systems and tools are pretty good about how they handle
these files.
Best regards,
Randall
On Jan 21, 2009, at 10:00 AM, John Verhaeg wrote:
I'd like to propose that we change our Eclipse preferences (or
the
associated preferences in whatever IDE you use) to force all created/
edited files to be saved with UTF-8 encoding and to use /n (LF) as
the end-of-line delimiter. I'd also like to convert all of the
existing files in the DNA repository to use this encoding and
delimiter.
Currently the files in the DNA SVN repository contain a mixture of
encoding formats and end-of-line delimiters based upon the default
behavior of the OS that was used to create them. With regard to
delimiters, Windows ends lines of text with \r\n (CR/LF), *nix with
\n (LF), and OS X with \r (CR). Eclipse apparently attempts to
maintain the encoding and delimiters used when the file was
originally created, but other editors and file manipulation tools
don't. This sometimes results in multiple delimiter techniques used
within the same file.
One of the main problems with this situation is many tools can't
handle this mixture of encodings and/or delimiters. Git, for
instance, relies upon \n only to determine what constitutes a line.
Thus, if you modify a single character in a git-managed file created
using OS X, then compare the file to the one in the repository, git
will report the entire file has changed. I've also seen problems in
the past where someone inserts a copyright symbol in a file header
comment from Windows, and subsequent compilations fail on a server
performing continuous builds using Ant.
Given that we do standardize our encoding technique, I doubt anyone
would object to the ubiquitous UTF-8 standard. Regarding the
delimiter, the two characters used by Windows increases the size of
each file needlessly and, considering DNA is a JBoss project,
Windows will probably be the least commonly used platform by
developers. The OS X seems inappropriate simply due to the number
of tools that assume the existence of line-feeds.
I'd like to get everyone's feedback on this proposal. Since the
second part of this proposal probably involves modifying a large
number of files in SVN, we'd obviously want to do this sooner rather
than later. Please comment when you get a chance.
Thanks,
John Verhaeg
Red Hat, Inc.
(314) 336-2950
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
6:14 p.m.
John,
Why don't you commit the change to the Eclipse preference file that's
in SVN, and developers can start grabbing that. We can then bulk
change the files after that.
Best regards,
Randall
On Jan 21, 2009, at 10:12 AM, Randall Hauch wrote:
Considering that we already have files with every combination of
line delimiter (though thankfully each file is consistent), has
anyone experienced problems in your development environments? If
so, please speak up. I know Eclipse handles them well enough, and I
suspect other Java tools do as well. And for the most part I think
the operating systems and tools are pretty good about how they
handle these files.
Best regards,
Randall
On Jan 21, 2009, at 10:00 AM, John Verhaeg wrote:
> I'd like to propose that we change our Eclipse preferences (or the
> associated preferences in whatever IDE you use) to force all
> created/edited files to be saved with UTF-8 encoding and to use /n
> (LF) as the end-of-line delimiter. I'd also like to convert all of
> the existing files in the DNA repository to use this encoding and
> delimiter.
>
> Currently the files in the DNA SVN repository contain a mixture of
> encoding formats and end-of-line delimiters based upon the default
> behavior of the OS that was used to create them. With regard to
> delimiters, Windows ends lines of text with \r\n (CR/LF), *nix with
> \n (LF), and OS X with \r (CR). Eclipse apparently attempts to
> maintain the encoding and delimiters used when the file was
> originally created, but other editors and file manipulation tools
> don't. This sometimes results in multiple delimiter techniques
> used within the same file.
>
> One of the main problems with this situation is many tools can't
> handle this mixture of encodings and/or delimiters. Git, for
> instance, relies upon \n only to determine what constitutes a
> line. Thus, if you modify a single character in a git-managed file
> created using OS X, then compare the file to the one in the
> repository, git will report the entire file has changed. I've also
> seen problems in the past where someone inserts a copyright symbol
> in a file header comment from Windows, and subsequent compilations
> fail on a server performing continuous builds using Ant.
>
> Given that we do standardize our encoding technique, I doubt anyone
> would object to the ubiquitous UTF-8 standard. Regarding the
> delimiter, the two characters used by Windows increases the size of
> each file needlessly and, considering DNA is a JBoss project,
> Windows will probably be the least commonly used platform by
> developers. The OS X seems inappropriate simply due to the number
> of tools that assume the existence of line-feeds.
>
> I'd like to get everyone's feedback on this proposal. Since the
> second part of this proposal probably involves modifying a large
> number of files in SVN, we'd obviously want to do this sooner
> rather than later. Please comment when you get a chance.
>
> Thanks,
>
> John Verhaeg
> Red Hat, Inc.
> (314) 336-2950
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
5606
days inactive
5607
days old
2 comments
2 participants
participants (2)
-
John Verhaeg -
Randall Hauch