jinx의 일부 설정을 gradle plugin으로 설정하면 개발자 DX가 더 좋을 것 같아 신청 했었음.

물론 한번에 된건 아니고 한 번 리젝을 받긴 했음. 리드미를 반드시 영어로 적어야 하는 듯?
영문 버전 리드미가 별도로 있어서 링크만 달아뒀었는데 그런거 까지는 확인 안해주시는거 같아서 메인 리드미를 영어 버전으로 바꿨음. 그리고 깃허브 계정과 연동이 안되어 있었다.

그리고 내부적으로 이게 너무 좁은 타깃의 도메인(회사 내부에서 쓴다거나)은 또 리젝 당할 확률이 높음. 사용법이 명확하지 않은 경우도 마찬가지인 듯. 그리고 너무 단순한 기능(뭐 헬로 월드 출력이라던지) 또한 거절당한다. 공식문서에 나와있음.

이제 이걸 기반으로 Jinx의 구체적인 사용법이나 예시등을 문서화할 필요가 있을 것 같다.
baseline이나 네이밍 전략이 있을 것이고.. 그리고 생각해보니 네이밍 전략에 대한 부분을 개발자가 인터페이스 구현을 하는 방식으로 열어줘도 좋을것 같다. 컬럼명에 대한 카멜/스네이크 케이스 지정이라던지 기타 등등..
그리고 내가 생각하는 주요 장점에 대해서도 조금 더 어필해봐야 할듯?

솔직히 아주 장기적으로 생각하고 있긴 했어서, aot 생태계 고려한 것, CI/CD에 통합 가능성, 하이버네이트 ddl auto와 비교했을때 차이점과 더 개선된 점..이라던지

또 개인적으로 써보고 느낀점은 이거 baseline 설정하는 부분을 VCS 개념을 일부 차용해서 비교하도록 하는게 조금 더 좋은 방법일 수 있겠음. 설정과 사용에 대한 DX 개선이 더 들어가야할 것 같다. 귀찮으면 진짜 쓰기 싫기 때문에

그냥 끝내기 뭐하니까 Gradle Plugin Portal의 컨트리뷰트 권고 사항에 대해 한글로 번역을 하고 마무리..ㅎㅎ

---

승인 과정 (Approval)

새 플러그인(또는 group ID / plugin ID 변경 시)은 Gradle 엔지니어가 수동으로 검토합니다. 최초 버전만 주로 검토하며, 이후 버전 업그레이드는 자동 승인되는 경우가 많습니다.

승인을 받기 위한 필수 조건

1. 실제 기능이 있어야 함

“Hello World” 수준이거나 아무 기능 없는 플러그인은 거부됩니다.

2. 문서화가 되어 있어야 함

description에 플러그인이 하는 일을 명확히 적어주세요 tags로 카테고리를 잘 나타내 주세요 website 또는 vcsUrl에 문서나 소스코드가 있어야 합니다

3. 플러그인 ID는 작성자를 나타내야 함

예시

GitHub 사용자라면 → io.github.본인아이디.플러그인명
회사 도메인이라면 → com.회사명.플러그인명 (또는 co.kr 등)
→ com.github.xxx 접두사는 더 이상 허용되지 않습니다 (Maven Central 정책과 동일)

4. SNAPSHOT 버전은 게시 불가

포크된 저장소에서 게시 금지 원본 저장소가 방치된 경우 등 예외는 협의 가능