Maven은 프록시 플러그인을 실행하기 전에 그 플러그인에 도달해야 한다

자동 프록시 플러그인은 네트워크 사이를 옮겨 다니는 노트북에 이상적으로 들린다. 하지만 곤란한 첫 요청이 하나 있다. Maven이 플러그인 자체를 받기 위해 프록시가 필요할 수 있다.

플러그인 목표는 Maven이 그 구현과 필요한 아티팩트를 확인하고 로드한 뒤에야 실행된다. 그 구현 내부의 프록시 검색은 구현이 시작되기 전에 실패하는 다운로드를 도울 수 없다. 완전히 정규화된 플러그인 좌표를 쓰면 접두사 조회를 피할 수 있지만, 빈 로컬 저장소에 플러그인 아티팩트가 나타나게 하지는 않는다.

오래된 Autoproxy Maven 플러그인이 이 차이를 보여 준다. 그 README는 proxy-vole을 통한 프록시 검색을 설명하지만, 목표를 호출하기 전에 플러그인을 로컬에 설치하는 것도 설명한다. 그것을 그 특정 설계의 전제 조건으로 보아야 하며, Maven이 보편적으로 브라우저 PAC 설정을 읽는다는 증거로 보아서는 안 된다.

첫 확인에 명시적인 경로를 준다

저장소 접근에 HTTP 프록시가 필요한 네트워크라면, 그 호출이 사용하는 Maven 설정에 적절한 활성 프록시를 구성한다. 허용된 공개 저장소 부트스트랩이라면 HTTP 프록시 목록에서 HTTP 후보를 고른다. 외부 경로 없이 접근 가능한 승인된 내부 저장소도 초기 접근 문제를 해결할 수 있다. 어느 방식이든 애플리케이션의 의존성만이 아니라 플러그인과 그 의존성을 모두 포함해야 한다.

이전에 채워진 로컬 저장소는 부트스트랩 요구 사항을 숨길 수 있다. 개발자 노트북에서의 성공은 새 CI 계정이 같은 빌드를 시작할 수 있음을 증명하지 않는다. 플러그인의 감지 로직을 바꾸기 전에 실패한 아티팩트와 단계를 살펴본다.

플러그인이 로드된 뒤에는 이후의 의존성 실패가 별개의 질문이 된다. 감지된 경로가 올바른지, 활성 Maven 전송이 그 결과 설정을 사용하는지다. 자동 감지를 유지할 가치가 있는지 결정할 때 이 두 실패 지점을 구분해 둔다.