Tôi đã thấy các chương trình như http://one-jar.sourceforge.net/ và http://fjep.sourceforge.net/index.html thúc đẩy việc lăn lọ ứng dụng của bạn và bất kỳ phụ thuộc nào vào một bình, thực thi.Ưu điểm/nhược điểm của việc xây dựng một cái lọ lớn như trái ngược với một số nhỏ hơn?
Lý do chính để/chống lại việc này là gì?
Mục đích:
Against:
Nói chung, đây thực sự là một cách tuyệt vời để tạo mẫu nhanh, nhưng có thể theo cách nếu được sử dụng trong một dự án lớn hơn.
Phân phối FTW! Nó dễ dàng hơn nhiều khi người dùng cuộn vào một.
Một lý do chính đáng mà tôi đã thấy tại nơi làm việc là do thực tế là một nhà cung cấp cung cấp các lọ hotfix cần phải đứng trước phiên bản gốc trong đường dẫn lớp.
Tuy nhiên, ứng dụng này được đưa ra thông qua java webstart (jnlp) và như của java phiên bản 6, thứ tự của các phụ thuộc tệp jar không còn được đảm bảo. Vì vậy, cách duy nhất để đảm bảo rằng các tệp lớp trùng lặp theo đúng trình tự là đóng gói chúng lại thành một uber jar, giữ lại các tệp lớp được vá mới nhất và loại bỏ các bản sao cũ hơn.
Giấy phép phân phối lại áp dụng cho các phụ thuộc là một lý do chính để xây dựng một lọ "uber". Khi người ta tạo ra một bình "uber", việc phân phối bất kỳ sự phụ thuộc nào xảy ra, thông qua việc phân phối bình "uber". Và ở các khu vực, trong trường hợp các luật lệ không bao quát đầy đủ kịch bản này, người ta có thể tự chịu trách nhiệm.
Ngoài ra, một số phụ thuộc thương mại thu được có thể cấm đóng gói lại các phụ thuộc, đặc biệt nếu phân phối ban đầu không được bảo toàn.
PS: Đây không phải là lời khuyên pháp lý. Bất cứ ai đọc điều này và tùy thuộc vào điều này để thực hiện các quyết định kinh doanh, nên được tư vấn một luật sư.
Mục đích:
Against:
Nói chung, nếu nó là một ứng dụng tiện ích nhỏ, tôi sẽ gói nó vào một lọ duy nhất. Đối với các ứng dụng lớn hơn (có thể sẽ yêu cầu trình cài đặt), hoặc nếu nó là thư viện để người khác sử dụng, tôi sẽ không bận tâm. Nó sẽ chỉ là một liên kết khác trong chuỗi những thứ có thể phá vỡ.
+1 cho trường hợp sử dụng rất thú vị – Rekin