maven script interpreter
1.6
버그를 발견했거나 멋진 새 기능에 대한 아이디어가 있습니까? 코드에 기여하는 것은 오픈 소스 커뮤니티에 무언가를 돌려줄 수 있는 좋은 방법입니다. 코드를 바로 살펴보기 전에, 우리가 모든 것을 파악할 수 있도록 기여자가 따라야 할 몇 가지 지침이 있습니다.
JIRA 계정이 있는지 확인하세요.
GitHub 계정이 있는지 확인하세요.
새로운 기능을 구현할 계획이라면 먼저 개발자 목록에서 변경 사항을 논의하는 것이 좋습니다. 이렇게 하면 Apache Maven의 범위에 포함되지 않는 것으로 간주되는 작업에 시간을 낭비하지 않도록 할 수 있습니다.
문제에 대한 티켓이 아직 존재하지 않는다고 가정하고 제출하세요.
버그인 경우 재현하는 단계를 포함하여 문제를 명확하게 설명합니다.
문제가 있는 것으로 알고 있는 가장 빠른 버전을 작성했는지 확인하세요.
GitHub에서 리포지토리를 포크합니다.
우리는 GitHub를 통해 Pull Request를 받아들입니다. 개발자 메일링 리스트는 기여자들의 주요 커뮤니케이션 채널입니다.
PR을 더 쉽게 적용할 수 있는 몇 가지 지침이 있습니다.
작업의 기반이 될 주제 브랜치를 만듭니다(일반적으로 마스터 브랜치입니다). 저장소 포크의 주제 브랜치에 변경 사항을 푸시합니다.
논리 단위를 커밋합니다.
원본 코드 스타일을 존중합니다. 동일한 코드 스타일을 사용하면 패치는 형식 문제로 인해 방해받지 않고 실제 차이점만 강조해야 합니다.
들여쓰기에는 공백만 사용하세요.
최소한의 차이점 생성 - 소스 코드 재포맷 또는 가져오기 구성과 같은 저장 작업을 비활성화합니다. 소스 코드를 다시 포맷해야 한다고 생각되면 이 변경 사항에 대해 별도의 PR을 만드세요.
커밋하기 전에 git diff --check 로 불필요한 공백을 확인하세요.
커밋 메시지가 올바른 형식인지 확인하세요. 커밋 메시지에는 JIRA 문제의 핵심이 포함되어야 합니다.
[MSHARED-XXX] - Subject of the JIRA Ticket Optional supplemental description.
변경 사항에 필요한 테스트(JUnit/IT)를 추가했는지 확인하세요.
mvn -Prun-its verify 로 모든 테스트를 실행하여 실수로 손상된 부분이 없는지 확인하세요.
Apache 조직의 저장소에 풀 요청을 제출합니다.
JIRA 티켓을 업데이트하고 티켓에 풀 요청 링크를 포함하세요.
정기적으로 기여할 계획이라면 기여자 라이센스 계약 제출을 고려해 보세요.
댓글 및 문서에 대한 사소한 변경 사항의 경우 항상 JIRA에서 새 티켓을 생성할 필요는 없습니다. 이 경우 커밋의 첫 번째 줄을 티켓 번호 대신 '(doc)'로 시작하는 것이 적절합니다.
패치 기여
Apache Maven 공유 구성 요소 프로젝트 페이지
기여자 라이센스 계약
일반 GitHub 문서
GitHub 풀 요청 문서
Apache Maven 트위터 계정
#freenode.org의 Maven IRC 채널
