1
버전이 지정된 외부 API를 사용하는 클래스가 포함 된 Java 패키지의 이름을 지정하는 방법에 대한 규칙이 있습니까?외부 API 버전 지정을위한 Java 패키지 이름 지정
우리는 서비스의 major-minor 의미 체계 버전 체계가 있다고 가정하고 해당 API의 특정 버전과 호환되고 해당 API에 바인딩 된 소비자를 구현해야합니다. 패키지 (및 클래스)의 이름을 지정하는 가장 좋은 방법은 무엇입니까?
현재 우리는 ${service}_${M}_${N} (M = 주 버전, N = 부 버전) 구성표를 사용하고 있습니다. 예 : com.example.theService_1_0.. 그러나 sonarqube는 관례와 일치하지 않는다고 불평하고 있습니다. 물론이 규칙을 비활성화 할 수는 있지만 모범 사례가 있는지 궁금합니다.
WebService, REST 및 CORBA에 대한 소비자 구현이 있으므로 REST에만 국한되지 않는 일반적인 접근 방식을 찾고 있습니다. 그리고 확실하지는 않지만, 인공물 버전 관리 (maven 에서처럼)는 API가 아닌 구현 버전과 관련되기 때문에 여기서 잘 작동합니다.
나는 api versioning 주위에 질문이 있지만 소비자가 아니라 생산자에 관한 것임을 알고 있습니다.
잠재적 인 불필요한 코드 재 작성을 의미하지는 않습니다. 제작자가 버전을 변경할 때마다 패키지 이름과 해당 클래스를 사용하는 모든 클래스의 모든 import 문을 변경해야합니다. – 7663233
필자는 금융 업계의 일부 프로젝트에서 코드 중복 비용과 나란히 나란히두고 소비자를 별도로 유지 관리하는 것으로 보아 하나의 소비자 버전으로 변경해도 다른 영향에는 영향을 미치지 않습니다. 새 버전이 나오면 (몇 년 후) 기존 코드를 복제하여 시작합니다. 그것은 기본적으로 비공유 접근 방식입니다. 확실히 실용적인 관행이지만, (더 나은?) 대안이 있는지 궁금합니다. –
대상 API 버전 다음에 패키지 이름을 지정하지 않습니다. 프로젝트는 특정 API 버전에 종속성을 선언해야하며, 다른 API 버전 (예 : 종속성 버전을 변경할 때)을 목표로 할 때마다 자체 버전 번호를 사용하여 프로젝트를 버전화해야합니다. 예 : myproject 버전 1.1 .8에서는 theapi 버전 2.3.0을 사용하고 myProject 버전 1.2.0에서는 theapi 버전 2.4.6을 사용합니다. – Berger