Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 480712 - [generator] don't insist on crlf in manifests
Summary: [generator] don't insist on crlf in manifests
Status: CLOSED DUPLICATE of bug 378980
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.8.4   Edit
Hardware: PC Mac OS X
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-26 23:09 EDT by Knut Wannheden CLA
Modified: 2016-09-11 00:49 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Knut Wannheden CLA 2015-10-26 23:09:22 EDT 
I think it would be nice if the org.eclipse.xtext.util.MergeableManifest class used by org.eclipse.xtext.generator.Generator would respect the org.eclipse.xtext.generator.Naming#lineDelimiter setting for the generation. Currently it insists on CRLF line feeds.

AFAICT there is no requirement that CRLF must be used in manifests. It's rather the opposite (any of CRLF, CR, or LF are accepted): https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#JARManifest.
Comment 1 Sebastian Zarnekow CLA 2015-10-27 03:42:55 EDT 
The spec doesn't demand CRLF but from looking at the code in java.util.jar.Manifest.write(OutputStream) CRLF is always used to write a manifest file.

We need to decide if we want to use that default as the only supported line delimiter or if we want to make it customizable.
Comment 2 Knut Wannheden CLA 2015-10-27 03:44:51 EDT 
OK. AFAIK the PDE tooling will use the platform default, but I am not 100% sure about that.
Comment 3 Sebastian Zarnekow CLA 2015-10-27 04:44:11 EDT 
After a brief offline discussion, there's a tendency towards configurable line endings also for the manifests.

While we're at it, we have to make sure that manifests are always UTF-8 encoded.
Comment 4 Knut Wannheden CLA 2016-09-11 00:49:51 EDT 

*** This bug has been marked as a duplicate of bug 378980 ***