Dự án Java: nên .classpath. Tệp dự án được cam kết vào kho lưu trữ?

Question

Tôi có nên kiểm tra tệp .project và .classpath của mình không?

Bạn tôi nói với tôi rằng tôi chỉ nên kiểm tra tệp .java và tệp build.xml để đảm bảo tính di động. Anh ấy nói ".classpath sẽ khiến bạn kém khả năng di chuyển trên môi trường khác. Dự án hoàn toàn là cài đặt nhật thực địa phương của bạn"

Tôi đồng ý với anh ta, nhưng một phần.

- Không kiểm tra trong tập tin .project sẽ làm cho sự phát triển của tôi kém hiệu quả (tôi có thể không đơn giản là "nhập khẩu" một mã số dự án từ một thư mục)

- Không kiểm tra trong classpath tập tin có vẻ OK với tôi (?) nếu build.xml của tôi được viết cẩn thận.

Ai cũng muốn chia sẻ kinh nghiệm của họ ở đây?

Answer 1

Không có gì sai khi kiểm tra trong .project và .classpath. Tôi sẽ làm như vậy, nếu build.xml của bạn không thể tạo cả hai tệp cho bạn. Như bạn đã nói, thật khó để bỏ lỡ những tập tin này khi bạn cố gắng tạo ra một không gian làm việc nhật thực mới.

Trước khi bạn đăng ký .classpath bạn nên chắc chắn rằng không có đường dẫn tuyệt đối nào trong đó. Chuyển đổi nó thành một liên quan với một trình soạn thảo văn bản.

Chỉnh sửa: Hoặc thậm chí tốt hơn, hãy sử dụng các biến đường dẫn nhật thực trong các đường dẫn tuyệt đối khác của bạn, như @ taylor-leese đã nhận xét.

Answer 2

Một điều tôi sẽ thận trọng khi kiểm tra tệp .classpath là đảm bảo bạn không tham chiếu tệp bên ngoài dự án của mình. Eclipse lưu trữ vị trí của các tệp này với một tệp đầy đủ và bạn cần phải đảm bảo các nhà phát triển khác có các tệp đó ở chính xác cùng một vị trí.

Answer 3

Không kiểm tra trong tập tin .project sẽ làm phát triển của tôi kém hiệu quả (Tôi có thể không đơn giản là "nhập khẩu" một mã số dự án từ một thư mục)

cho vấn đề này, bạn có thể chọn để tạo dự án mới và nhập nguồn hiện có.

một vấn đề với các tệp cụ thể như IDE. Các nhà phát triển khác có thể muốn sử dụng một IDE khác để phát triển dự án, để họ có thể thêm một loại tệp dự án khác. điều này sẽ làm cho repo của bạn lộn xộn.

Answer 4

Không có vấn đề về việc kiểm tra tệp .classpath và .project trong kho lưu trữ. Nó sẽ giúp các nhà phát triển sử dụng Eclipse để phát triển nhanh hơn.

Cảnh báo: Đảm bảo tệp .classpath của bạn chỉ tham chiếu các tạo phẩm được kiểm tra vào kho lưu trữ với dự án hoặc có thể lấy tự động (chẳng hạn như tạo tác maven).

Answer 5

Tôi muốn đăng ký .project và .classpath.

Điều này sẽ hữu ích khi dự án này đang được chia sẻ bởi nhiều nhà phát triển. Nó trở thành dễ dàng và nhanh hơn để thiết lập phát triển env. đơn giản bằng cách nhập này dưới dạng dự án hiện có trên bất kỳ hệ thống nào sử dụng nhật thực.

Chỉ cần thận trọng ở đây là đường dẫn lớp có liên quan đến dự án.

Answer 6

Tôi không thực sự biết các tệp tùy chọn nhật thực, nhưng với IntelliJ, các tệp đó là hệ điều hành agnostics, có nghĩa là nó sẽ không làm hỏng tính di động của bạn. Trừ khi bạn xác định các thư viện với một đường dẫn đầy đủ đến hệ thống của bạn (Điều đó sẽ khá nguy hiểm/ngu ngốc).

Khi bạn chia sẻ tùy chọn, bạn chắc chắn rằng mọi người sẽ làm việc với cùng các điều kiện trong dự án (cấu hình plugin, mã hóa, cấu hình [cho intelliJ]) thực sự có thể là một điều tốt.

Nó không làm phiền tôi khi một số tệp Eclipse ở đây và tôi nghĩ rằng nó không nên/không thực sự làm phiền các nhà phát triển khác khi một số tệp ẩn nằm ở đó.

Answer 7

Chúng tôi đăng ký. Project và .classpath. Với ProjectSet, điều này cho phép chúng ta kiểm tra các không gian làm việc phức tạp với một "Import Team ProjectSet"

Answer 8

Câu hỏi quan trọng với tất cả các tệp như vậy là "Chúng có thể được sao chép tự động không?" Nếu không, hãy kiểm tra chúng vào kiểm soát nguồn.

Trong trường hợp này, tôi muốn nói "có", trừ khi bạn đang sử dụng maven, trong đó có m2eclipse và plugin eclipse để tạo chúng cho bạn.

Answer 9

Với 2 xu của tôi, tôi sẽ đánh giá nó là một thực tế không tốt. Các dự án không nên gắn với một IDE, và đặc biệt không nên gắn với một phiên bản cụ thể của một IDE.

Kiểm tra trong các tệp cấu hình Eclipse có thể hoạt động tốt cho các dự án đơn giản và ngắn hạn. Đối với các dự án lớn hơn được phát triển trong vài năm, điều này thường sẽ gây ra nhiều rắc rối hơn, vì các phiên bản IDE thay đổi và các tệp cấu hình dự án thì không. Chỉ cần tưởng tượng kiểm tra trong một nhánh 2 năm tuổi với các tệp cấu hình Eclipse 2.0 trong Eclipse 4.3 với một số thư viện tùy chỉnh và tích hợp m2e ... Không có gì thú vị cả ...

Answer 10

Tôi thường có một câu hỏi tương tự, tổng quát hơn. Vấn đề cơ bản là:

• tôi đang cam kết tệp nào cho me?
• tôi đang cam kết tệp nào cho những người khác?
• → Làm cách nào để kết hợp cả hai mục tiêu "phiên bản"?

tôi đề nghị thảo luận there này, vì vậy bạn có thể tìm thêm chi tiết về vấn đề này, cùng với các giải pháp thú vị :)

---

Người tôi thích nhất là việc sử dụng git submodule: giữ .project tập tin của bạn , v.v. trong repo cam kết riêng tư. Và làm cho sản phẩm src cuối cùng, tinh tế của bạn thành gọn gàng submodule nugget: một repo công cộng.

project/ # root module 
| .git # private repo 
| .project 
| .classpath 
| momsNumber.txt 
+---src/  # submodule 
| | .git # public repo 
| | main.java 
| +---package/ 
| | | Etc.java 

---

See there anyway.