2012-03-01 37 views
6

Giả sử bạn có bộ ứng dụng web sử dụng các phiên bản khác nhau của một thư viện chung như Spring. Tôi có một thư viện logic kinh doanh cũng sử dụng thư viện chung này. Cho đến nay không có vấn đề gì, nhưng trên đường đi, một phiên bản của thư viện chung đã thay đổi định nghĩa lớp trừu tượng và phá vỡ thư viện logic nghiệp vụ.Phát hiện các phụ thuộc không tương thích trong Maven?

Vì vậy, tôi kết thúc với một bảng phiên bản tương thích trông như thế này ...

business-lib-version | common-lib-version 
     1.0   |  1.0 
     1.1   |  2.0 

Tôi không muốn phiên bản kinh doanh lib để lái xe phiên bản lib chung trong việc áp dụng tiêu thụ. Thay vào đó, tôi muốn chọn phiên bản chính xác của lib doanh nghiệp dựa trên lib chung. Tôi khá chắc chắn điều đó là không thể vì vậy tôi chuyển sang câu hỏi chính.

Có cách nào thanh lịch để phát hiện tính không tương thích của phiên bản không? Lý tưởng nhất là tôi muốn một giải pháp xây dựng thời gian, nếu không một giải pháp thời gian chạy sớm sẽ là ok.

Tôi đã thử sử dụng phạm vi phiên bản trong Maven nhưng điều này đã gây ra cho chúng tôi nhiều sự cố do cách Maven sắp xếp các phiên bản ở định dạng phiên bản không chuẩn và chúng tôi cũng có các vấn đề khác nhau trong việc giải quyết các dải ô chính xác tại thời gian xây dựng.

+0

Bằng cách "không tương thích", bạn có chỉ đơn giản là các phiên bản khác nhau hoặc sự cố thực sự không? –

+0

@DaveNewton: một hoặc cả hai tại thời điểm này. Tôi chỉ đơn giản là tìm kiếm giải pháp ít ngạc nhiên nhất. –

Trả lời

4

Ning dependency-versions-check Plugin Maven sẽ không thành công nếu phiên bản phụ thuộc đã bị tình trạng phụ thuộc khác giữ lại. Nó sẽ không sửa chữa nó cho bạn, nhưng nó ít nhất sẽ cho bạn biết!

+0

Vấn đề ở đây là nó đòi hỏi các ứng dụng tiêu thụ để có plugin bao gồm. Có lẽ nó có thể được thêm vào một môi trường chuẩn CI xây dựng. Tôi e rằng điều này có thể phá vỡ các phụ thuộc khác là ok với việc sử dụng một phiên bản mới hơn. Tôi vẫn còn rất nhiều thứ để đọc trong tài liệu. –

+0

Chúng tôi bao gồm nó trong một "cơ sở" pom rằng tất cả các dự án của chúng tôi kế thừa từ, vì vậy tất cả các dự án có được nó (và cấu hình khác) –

+0

Đối với phiên bản, nó giả định rằng bạn có một chính sách phiên bản hợp lý bạn thực sự làm theo (ví dụ như chính. minor.patch) và vì vậy nó sẽ cho phép bạn quay trở lại từ 1.7.2 đến 1.7.1 nhưng không quay lại 1.6.9 –

0

Tôi không biết cách nào để thực hiện điều này tốt - lúc chạy hoặc thậm chí ở thời gian xây dựng. Không có cơ chế tiêu chuẩn để xác định phiên bản của các gói mà không cần điều tra các tệp kê khai hoặc tên tệp jar - đó sẽ là một hack tốt nhất. Có lẽ có một plugin maven mà tôi không biết về điều này không automagically nhưng tôi không biết một.

Chúng tôi chỉ sửa các phiên bản của thư viện chúng tôi cần cho mã của chúng tôi và nâng cấp khi chúng tôi cần hoặc vì chúng tôi cần chức năng bổ sung hoặc phụ thuộc khác. Thông thường chúng ta đang ở phía trước phụ thuộc khác vì vậy chúng tôi đặt một dấu trừ tiêu biểu trong định nghĩa sự phụ thuộc của chúng tôi trong pom.xml:

<dependency> 
    <groupId>org.springframework</groupId> 
    <artifactId>spring</artifactId> 
    <version>${spring-version}</version> 
    <exclusions> 
     <exclusion> 
      <groupId>commons-logging</groupId> 
      <artifactId>commons-logging</artifactId> 
     </exclusion> 

này cho phép chúng ta phụ thuộc vào một phiên bản sau của commons-logging.

Nếu, tuy nhiên, bạn đang sử dụng 1.0 thư viện nhưng một trong các phụ thuộc của bạn đang sử dụng 2.0 thì bạn sẽ phải thử exclusion và xem phụ thuộc có chạy với 1.0 hay thậm chí là biên dịch hay không. Nếu không thì bạn sẽ bị buộc phải nâng cấp mã của bạn để làm việc với 2.0 hoặc hạ cấp phụ thuộc.

Rất tiếc, tôi không thể trợ giúp thêm.

Các vấn đề liên quan