이 시리즈의 첫 번째 부분에서, 우리는 첫 번째 다중 플랫폼 라이브러리를 만들고 이를 로컬 Maven에 발표했다.공개되기 전에, 다중 플랫폼 발표 형식을 이해하기 위해 이미 발표된 부품을 먼저 발견합시다.
TL;DR: Kotlin Gradle 플러그인은 자동으로 도서관 출판물을 만들고 구성하므로 출판물 프로젝트에 대한 자세한 정보를 알 필요가 없습니다.만약 당신이 궁금하다면, 우리 토론을 합시다!

너의 도서관 구조 발견

만약 이전에 일반적인 플랫폼 (예:android) 라이브러리를 발표한 적이 있다면, 다중 플랫폼 라이브러리의 발표 형식 차이가 매우 크다는 것을 알 수 있습니다.한 버전의 라이브러리에는 여러 개의 부품이 있는데, 그것들의 내용 형식이 다르고 (.jar vs.klib) 원본 집합의 수량과 결과 부품의 수량이 일치하지 않습니다.
다중 플랫폼 라이브러리에 있어서 일반적인 발표는 부족하기 때문이다.일반 라이브러리에 비해 다중 플랫폼 라이브러리는 더욱 복잡한 구조를 가지기 때문에 출판물도 그리 자질구레하지 않다.다음은 기억해야 할 관건적인 차이점이다.

다중 플랫폼 라이브러리는 여러 부분으로 구성된다. expect 성명이 있는 공공 부분과 실제 실현된 플랫폼의 특정 부분이다.

플랫폼에 특정한 코드는 유사한 플랫폼에서 공유할 수 있다(예를 들어 iOS 장치와 아날로그 사이에서 공유된 원본 집중이나 모든 데스크톱 플랫폼의 공유 코드).

Kotlin/본기 교차 컴파일링의 제한으로 여러 호스트에서 이 위젯을 모두 발표할 수 있습니다.예를 들어 iOS나 macOS의 공작물은 Mac OS에서만 구축할 수 있다.

이러한 모든 복잡성을 고려하여 일반적인 멀티플랫폼 의존 관계를 추가하려면 build.gradle 파일에 코드를 한 줄만 입력하면 됩니다.

dependencies {
    implementation("io.github.katerinapetrova:mpp-sample-lib:1.0.0")
}

그렇다면 이런 마법은 어떻게 작용하는가?Maven은 대상, 소스 코드 세트 및 컴파일을 사용하지 않습니다.항목만 조작합니다.하나의 프로젝트는 우리가 세운 모든 것이고, 또한 우리가 의지할 수 있는 것이다.모든 항목은 그룹 Id,artifactId,version에 의해 정의되며, Maven은 이 세 필드를 좌표계로 사용합니다.이것은 붙여넣기 의존 문자열을 구축할 때 사용하는 방법입니다.그레델 서류.이 좌표들은 a에서 정의한 것이다.pom 파일 - Maven 프로젝트의 XML 표현입니다.이제 릴리즈된 라이브러리의 로컬 Maven 폴더에 포함된 내용을 살펴보겠습니다.

우리는 단지 하나의 라이브러리만 발표했지만, 여러 개의 폴더가 있다.모든 폴더는 하나의 단독 마븐 프로젝트를 대표하며, 서로 다른 작업과 작업을 포함합니다.pom 파일은 프로젝트를 설명합니다. (프로젝트의 이름은pom artifactId 글자에 저장되어 있기 때문입니다.)
따라서 Kotlin Gradle 플러그인은 출판물을 만들었고 maven-publish 플러그인은 이 출판물을 이용하여 Kotlin 멀티플랫폼 라이브러리의 원본을 Maven 부품에 비추어 소비자 프로젝트에서Gradle 모듈로 의존할 수 있다.일은 이렇다.

이러한 변화의 핵심을 살펴보겠습니다.

각 목표마다 단독 출판물이 있다.이진 형식은 대상 컴파일러 백엔드에 따라 다릅니다.

.Kotlin/JVM 클래스 파일이 있는jar

.맞서다js 또는.klibwhen using IR Compiler for Kotlin/JS

.Kotlin klib/로컬

도서관 전체를 대표하는 추가 뿌리 출판물이 하나 더 있다.그것은 두 가지 중요한 부분으로 구성되어 있다.

Kotlin은 도서관의 일반적인 리소스를 나타냅니다.Kotlin toolchain은 공용 코드에서 라이브러리에 이르는 공용 코드의 정확도와 세분화 의존 관계를 제공하는 데 사용됩니다.

Gradle Module MetadataGradle은 공공 소스에 집중된 루트 작업에 의존할 때 라이브러리에서 플랫폼에 특정한 부분을 찾을 수 있는 곳을 알려줍니다.이것이 바로 공공 소스 코드 집중

의 라이브러리에 단일 의존 항목을 작성할 수 있도록 하는 이유입니다.

With the hierarchical project structure enabled 라이브러리의 중간 원본 집합의 API가 라이브러리 부품에 삽입됩니다(이 집합이 구분된 목표에 따라 공용 또는 플랫폼).

이 전환은 사소해 보이지 않고, 묘사된 요점은 빙산의 일각에 불과하지만, 좋은 소식은 모든 작업이 Kotlin Gradle 플러그인으로 이루어졌다는 것이다.관련 게시는 자동으로 작성되고 구성되므로 수동으로 작성할 필요가 없습니다.이것은 실수할 확률을 크게 낮추었다. 특히 유행에 맞는 설정이다.🎉
출판물 양식의 세부 사항을 깊이 있게 알고 싶다면, 코틀린 멀티플랫폼 팀의 디마 사비노프 (Dima Savinov) 의 멋진 강연을 보시기 바랍니다.
이제 우리 도서관이 세계를 향해 나아가는 주요 목표로 돌아가자!이 시리즈의 마지막 부분을 보십시오. Maven Central 출판 과정을 안내합니다.👀