On 2014-10-11, Kristian Rosenvold wrote:
Piñata encodes as NFC on my mac, which is correct. I am not sure if
the NFD issue is for older macs, but at least it looks good here.
Great. It may be older macs or older Java.
Stefan
+1 for UTF-8 by default
IMHO, nobody knows: everybody just want that it works (TM)
I found the spec: appendix D2 APPENDIX D - Language Encoding (EFS) of
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
this does not give the date when this bit was reserved, but seems quite old: I
don't
Piñata encodes as NFC on my mac, which is correct. I am not sure if
the NFD issue is for older macs, but at least it looks good here.
Kristian
2014-10-10 18:22 GMT+02:00 Stefan Bodewig bode...@apache.org:
On 2014-10-10, Kristian Rosenvold wrote:
I will investigate some modern windows. I
Currently plexus-archiver uses platform encoding for zip file names if
none is specified. This is compliant with traditional Zip history.
But zip understood this is a problem and introduced a LEF flag,
which basically means all entries must be UTF-8.
I would like to switch defaults in plexus zip
As this is a step towards reproducable builds I see this as a good thing.
Depending on platform defaults should be punished...:-)
/Anders
On Fri, Oct 10, 2014 at 8:26 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Currently plexus-archiver uses platform encoding for zip file
Hi,
+1 from too...
On 10/10/14 8:45 AM, Anders Hammar wrote:
As this is a step towards reproducable builds I see this as a good thing.
Depending on platform defaults should be punished...:-)
Yes... ;-)
/Anders
On Fri, Oct 10, 2014 at 8:26 AM, Kristian Rosenvold
Hi Kristina,
just a question on this topic...does currently jar from plexus-archiver
already behave like this and uses UTF-8 encoding always ? Or is this
platform dependent?
On 10/10/14 8:26 AM, Kristian Rosenvold wrote:
Currently plexus-archiver uses platform encoding for zip file names
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
The JAR archiver does this already, since its part of the jar spec.
Kristian
2014-10-10 11:58 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de:
Hi Kristina,
just a
I am looking at all the encoding-related issues in assembly now btw.
Kristian
2014-10-10 12:16 GMT+02:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
The JAR
Hi Kristian,
On 10/10/14 12:16 PM, Kristian Rosenvold wrote:
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
Ok...so i think this issue http://jira.codehaus.org/browse/MJAR-135 is
related to this behaviour as
On 2014-10-10, Kristian Rosenvold wrote:
This will break builds for people that actually *want* archives in
file.encoding; they will need to explicitly specify encoding to get
that encoding. To my understanding this is not really an issue, LEF
support is ancient history.
At the time where I
I suspect defaulting to UTF-8/LEF will work ok for most people, I
will do some tests on windows.
There's probably 1 billion chinese that rely on CP936 platform default
encoding on windows XP (IE6
all over again) but I suspect they will be better of making an
explicit specification of the
On 2014-10-10, Kristian Rosenvold wrote:
I will investigate some modern windows. I suppose this may cook down
to various unicode normalization forms on different OS'es. Does
commons compress deal with mac-os unicode normalization ? (e.g does it
handle Piñata on mac over to a PC ) ?
TBH I'm
13 matches
Mail list logo
