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
-
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 :
> On 2014-10-10, Kristian Rosenvold wrote:
>
>> I will investigate some modern windows. I suppose this may co
+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
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'
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 en
2014-10-10 12:47 GMT+02:00 Karl Heinz Marbaise :
> Ok...so i think this issue http://jira.codehaus.org/browse/MJAR-135 is
> related to this behaviour as wellHm...may be more related to directory
> name encoding ..?
I responded directly to MJAR-135.
>> The JAR archiver does this already, sinc
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
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 well...
I am looking at "all" the encoding-related issues in assembly now btw.
Kristian
2014-10-10 12:16 GMT+02:00 Kristian Rosenvold :
> 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,
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 :
> Hi Kristina,
>
>
> just a question on this
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 i
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 <
kristian.rosenv...@gmail
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 na
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
14 matches
Mail list logo