$LEIN JVM OPTS가 -Dfile을 덮어쓰도록 허용합니다.부호화

묘사

이것은 JVM이 UTF-8 이외의 인코딩으로 실행할 수 있도록 한다.내 자신의 용례는 테스트를 실행하는 것이다. 문자 인코딩/디코딩 호출에서 UTF-8을 지정하는 것을 잊었는지 확인하는 것이다.
다음은 이러한 행동에 대한 회귀 테스트입니다.

$ LEIN_JVM_OPTS='-Dfile.encoding=ASCII' bin/lein run -m clojure.main -e '(System/getProperty "file.encoding")'
"ASCII"

(java.nio.charset.Charset/defaultCharset)는 양보해야 한다#<US_ASCII US-ASCII>.

토론 #1

나도 LEIN_JAVA_CMD 이전의 줄에 이 평론을 추가하는 것을 고려하고 있다. # file.encoding is intentionally overrideable.
또 다른 생각은 LEIN JVM 옵션이 더 많은 내용을 덮어쓰기 위해 매개 변수 목록에서 아래로 이동해야 하는가?스케줄러:안 될 게 뭐 있어?

토론 #2

이것은 프로젝트 JVM이 아닌 Leiningen의 자신의 JVM에 대한 인코딩입니다. 맞습니까?leiningen.original.pwd 및 leiningen.script 이외의 내용을 덮어쓸 수 있도록 아래로 이동합니다.

토론 #셋

이것은 lein 자신의 JVM에 관한 것이 아니지만 이 줄은 둘을 연결시킨다.
https://github.com/technomancy/leiningen/blob/f95a10d79bee59fc9b8eb4ff65efb6b04273d11c/leiningen-core/src/leiningen/core/eval.clj#L116
너 그거 알아? 이거 너무 바보야.이 파일을 덮어쓰기 위해 l.c.eval/get-jvm-args에 패치를 제출해야 합니다.사용자 정의 프로필을 사용하여 인코딩합니다.아마~@(:jvm-opts project)가 마지막일 거예요.아, 알겠습니다.예, Leiningen의 JVM에서만 시스템 속성을 상속합니다.하지만 이것은 옳다.만약

토론 #4

에서 설정한 내용이 특정한 항목의 내용을 덮어썼다면, 그것은 틀림없이 버그일 것이다.bin/lein 당신은 l.c.eval/get-jvm-args가 환경 값을 목록의 첫머리에 놓는 것이 여전히 정확하다고 생각합니까?나는 어떤 방향에서든 논쟁을 볼 수 있다.
이 PR:jvm 을 수정하여 eval 목록의 맨 아래에 선택합니다.clj 및 move LEIN JVM 은 bin/LEIN에서

토론 #5

속성을 선택하기 전에 선택합니다.leiningen.* 이전에 이 메일을 보냈지만 GitHub에서 삭제한 것이 틀림없습니다.
일반적인 법칙은 더 높은 특이성이 이기는 것이다. 이것이 바로 왜
프로젝트 등급의 것이 사용자 등급의 설정보다 낫고, 사용자 등급의 설정이 낫다.
설정은 Leiningen에 내장됩니다.그러나 환경 변수는 이상한 문제이다
중간 입장은 시스템 범위 (in.profile) 내에서 설정할 수 있다는 것이다
혹은 아무거나) 매번 호출에 근거하여 해석할 수 있다.
현재의 불일치성.
다른 (더 좋을 수도 있는) 방법이 있어야 한다는 것을 감안하여 설정하다
시스템 범위나 사용자 범위의 설정은 환경 변수가 아니라
만약 누군가가 환경 변수를 설정하고 있다면
매번 호출되는 기초 위에서 진행되기 때문에 가장 구체적이기 때문에
그것은 다른 설정보다 낫다.
이런 추리는 합리적입니까?

토론 #6

나는 이것이 옳고 도덕적으로도 옳다고 생각하지만 이것은 돌파적인 변화가 될 것이다. 자세히 생각해 보면 이것은 감동적인 변화이다. jvm 옵션도 그럴 수 있다(가능성은 적지만)나는 가장 보수적인 방법은 파일을 이동하는 것이라고 생각한다.인코딩 기본값은 목록에 비교적 높은 위치에 있고 다른 모든 내용은 3.0까지 그대로 유지됩니다.

토론 #7

일반적인 법칙은 더 높은 특이성이 이기는 것이다. 이것이 바로 왜
프로젝트 등급의 것이 사용자 등급의 설정보다 낫고, 사용자 등급의 설정이 낫다.
설정은 Leiningen에 내장됩니다.그러나 환경 변수는 이상한 문제이다
중간 입장은 시스템 범위 (in.profile) 내에서 설정할 수 있다는 것이다
혹은 아무거나) 매번 호출에 근거하여 해석할 수 있다.
현재의 불일치성.
다른 (더 좋을 수도 있는) 방법이 있어야 한다는 것을 감안하여 설정하다
시스템 범위나 사용자 범위의 설정은 환경 변수가 아니라
만약 누군가가 환경 변수를 설정하고 있다면
매번 호출되는 기초 위에서 진행되기 때문에 가장 구체적이기 때문에
그것은 다른 설정보다 낫다.
이것은 합리적인 추리입니까?

토론 #8

추리는 합리적이라고 생각합니다. 프로젝트 지도 설정을 수정하는 환경 변수가 기본적으로 열려 있지 않은 것이 합리적이기 때문에 가장 높은 특이성을 가져야 한다고 가정합니다.저도 @timmc의 관점에 동의합니다. 이것은 afaik이 기록되지 않았음에도 불구하고 돌파적인 변화입니다.

토론 #9

네, 여기 좀 더 보수적인 변화가 있습니다.이제 항목에서 다음 작업을 수행할 수 있습니다.
좋다.다른 질문을 마음대로 열어 나중에 호환되지 않는 변경 사항을 알려 주십시오.