Tại sao maven? Những lợi ích là gì? [đóng cửa]

Những lợi ích chính của việc sử dụng maven so với kiến ​​nói là gì? Nó dường như là một sự phiền toái hơn là một công cụ hữu ích. Tôi sử dụng maven 2, với Java EE đơn giản (không có m2eclipse) và tomcat.

Những người ủng hộ maven tin rằng

1. Maven cho phép bạn có được các gói phụ thuộc dễ dàng

2. Maven buộc bạn phải có cấu trúc thư mục chuẩn

Theo kinh nghiệm của tôi

1. Tìm ra các phụ thuộc gói thực sự không khó. Bạn hiếm khi làm điều đó anyway. Có lẽ một lần trong quá trình thiết lập dự án và một vài lần nữa trong quá trình nâng cấp. Với maven, cuối cùng bạn sẽ sửa chữa các phụ thuộc không khớp, các poms được viết xấu và thực hiện các loại trừ gói.

2. Chu kỳ FIX-COMPILE-DEPLOY-DEBUG chậm, giết chết năng suất. Đây là chuôi chính của tôi. Bạn thực hiện một thay đổi, bạn phải đợi maven build khởi động và chờ nó triển khai. Không có triển khai nóng nào.

Hay tôi chỉ làm sai? Xin hãy chỉ cho tôi đi đúng hướng, tôi là tất cả tai.

Tìm ra các phụ thuộc gói thực sự không khó. Bạn hiếm khi làm điều đó anyway. Có lẽ một lần trong quá trình thiết lập dự án và một vài lần nữa trong quá trình nâng cấp. Với maven, cuối cùng bạn sẽ sửa chữa các phụ thuộc không khớp, các poms được viết xấu và thực hiện các loại trừ gói.

Không khó lắm đâu ... cho các dự án đồ chơi. Nhưng các dự án tôi làm có rất nhiều, rất nhiều trong số đó, và tôi rất vui khi có được chúng một cách liên tục, để có một kế hoạch đặt tên chuẩn cho chúng. Quản lý tất cả điều này bằng tay sẽ là một cơn ác mộng.

Và vâng, đôi khi bạn phải làm việc trên sự hội tụ của các phụ thuộc. Nhưng hãy nghĩ về nó hai lần, đây không phải là vốn có của Maven, đây là vốn có cho bất kỳ hệ thống nào sử dụng các phụ thuộc (và tôi đang nói về các phụ thuộc Java nói chung ở đây).

Vì vậy, với Ant, bạn phải thực hiện cùng một công việc ngoại trừ việc bạn phải làm mọi thứ theo cách thủ công: lấy một số phiên bản của dự án A và các phụ thuộc của nó, lấy một số phiên bản của dự án B và các phụ thuộc của nó, tự tìm ra phiên bản chính xác mà chúng sử dụng, kiểm tra rằng họ không chồng chéo, kiểm tra rằng họ không tương thích, vv Chào mừng đến địa ngục.

Mặt khác, Maven hỗ trợ quản lý phụ thuộc và sẽ truy xuất chúng liên tục cho tôi và cung cấp cho tôi công cụ tôi cần để quản lý sự phức tạp vốn có của quản lý phụ thuộc : Tôi có thể phân tích cây phụ thuộc, kiểm soát các phiên bản được sử dụng trong phụ thuộc bắc cầu, loại trừ một số chúng nếu được yêu cầu, điều khiển sự hội tụ trên các mô-đun, v.v. Không có phép thuật. Nhưng ít nhất bạn có hỗ trợ.

Và đừng quên rằng quản lý phụ thuộc chỉ là một phần nhỏ trong những gì Maven cung cấp, còn nhiều hơn thế (thậm chí không đề cập đến các công cụ khác tích hợp độc đáo với Maven, ví dụ Sonar ).

Chu kỳ FIX-COMPILE-DEPLOY-DEBUG chậm, giết chết năng suất. Đây là chuôi chính của tôi. Bạn thực hiện một thay đổi, bạn phải đợi maven build khởi động và chờ nó triển khai. Không có triển khai nóng nào.

Đầu tiên, tại sao bạn sử dụng Maven như thế này? Tôi không. Tôi sử dụng IDE của mình để viết các bài kiểm tra, viết mã cho đến khi chúng vượt qua, tái cấu trúc, triển khai, triển khai nóng và chạy bản dựng Maven cục bộ khi tôi hoàn thành, trước khi cam kết, để đảm bảo tôi sẽ không phá vỡ bản dựng liên tục.

Thứ hai, tôi không chắc việc sử dụng Ant sẽ giúp mọi thứ tốt hơn nhiều. Và theo kinh nghiệm của tôi, các bản dựng Maven mô-đun sử dụng các phụ thuộc nhị phân cho tôi thời gian xây dựng nhanh hơn các bản dựng Ant nguyên khối điển hình. Dù sao, hãy xem Maven Shell để sẵn sàng (tái) sử dụng môi trường Maven (điều này thật tuyệt vời).

Vì vậy, cuối cùng, và tôi rất tiếc phải nói như vậy, thực sự không phải Maven đang giết chết năng suất của bạn, mà là bạn đang lạm dụng các công cụ của mình. Và nếu bạn không hài lòng với nó, thì, tôi có thể nói gì, đừng sử dụng nó. Cá nhân tôi đang sử dụng Maven từ năm 2003 và tôi không bao giờ nhìn lại.

Maven có thể được coi là công cụ phát triển dự án hoàn chỉnh chứ không chỉ là công cụ xây dựng như Ant. Bạn nên sử dụng IDE Eclipse với plugin maven để khắc phục tất cả các vấn đề của bạn.

Dưới đây là một vài ưu điểm của Maven, được trích dẫn từ Lợi ích của việc sử dụng trang Maven :

Henning

• thiết lập dự án nhanh chóng, không có tệp build.xml phức tạp, chỉ cần POM và đi
• tất cả các nhà phát triển trong một dự án đều sử dụng các phụ thuộc jar giống nhau do POM tập trung.
• nhận được một số báo cáo và số liệu cho một dự án "miễn phí"
• giảm kích thước phân phối nguồn, vì các lọ có thể được kéo từ một vị trí trung tâm

Emmanuel Venisse

• có rất nhiều mục tiêu để không cần thiết phải phát triển một số phần quy trình xây dựng cụ thể trái với ANT, chúng tôi có thể sử dụng lại các tác vụ ANT hiện có trong quy trình xây dựng với plugin chống lỗi

Jesse Mcconnell

• Thúc đẩy thiết kế mô-đun của mã. bằng cách đơn giản để quản lý các dự án mulitple, nó cho phép thiết kế được đặt thành các phần logic, kết hợp các phần này với nhau thông qua việc sử dụng theo dõi phụ thuộc trong các tệp pom.
• Thực thi thiết kế mô-đun của mã. Thật dễ dàng để trả tiền dịch vụ môi cho mã mô-đun, nhưng khi mã nằm trong các dự án biên dịch riêng biệt, không thể vượt qua các tham chiếu giữa các mô-đun mã trừ khi bạn đặc biệt cho phép nó trong quản lý phụ thuộc của mình ... không có 'Tôi sẽ chỉ cần làm điều này bây giờ và sửa chữa nó sau này 'triển khai.
• Quản lý phụ thuộc được tuyên bố rõ ràng. với cơ chế quản lý phụ thuộc, bạn phải cố gắng cải tiến phiên bản jar của mình ... không có vấn đề kinh điển nào về 'phiên bản này của jar nhà cung cấp này là gì?' Và thiết lập nó trên một dự án hiện có sẽ loại bỏ các mớ hỗn độn hiện có nếu nó bị buộc phải tạo các phiên bản 'không xác định' trong kho lưu trữ của bạn để có được mọi thứ và chạy ... điều đó hoặc nói dối với chính bạn rằng bạn biết phiên bản thực tế của ABC.jar.
• vòng đời được gõ mạnh mẽ có một vòng đời được xác định mạnh mẽ rằng một hệ thống phần mềm đi từ lúc bắt đầu xây dựng đến cuối ... và người dùng được phép trộn và kết hợp hệ thống của họ với vòng đời thay vì tự lắp ráp vòng đời của mình. . điều này có thêm lợi ích là cho phép mọi người chuyển từ dự án này sang dự án khác và nói bằng cách sử dụng cùng một từ vựng về mặt xây dựng phần mềm

Vincent Massol

• Động lực lớn hơn: Ant bây giờ là di sản và không di chuyển nhanh về phía trước. Maven đang tiến lên rất nhanh và có tiềm năng có nhiều công cụ giá trị cao xung quanh Maven (CI, dự án Bảng điều khiển, tích hợp IDE, v.v.).

Tìm ra sự phụ thuộc cho các dự án nhỏ không khó. Nhưng một khi bạn bắt đầu đối phó với một cây phụ thuộc với hàng trăm phụ thuộc, mọi thứ có thể dễ dàng vượt khỏi tầm tay. (Tôi đang nói từ kinh nghiệm ở đây ...)

Điểm khác là nếu bạn sử dụng IDE với trình biên dịch gia tăng và hỗ trợ Maven (như Eclipse + m2eclipse), thì bạn sẽ có thể thiết lập kiểm tra và triển khai chỉnh sửa / biên dịch / nóng.

Cá nhân tôi không làm điều này bởi vì tôi đã không tin vào chế độ phát triển này do những trải nghiệm tồi tệ trong quá khứ (trước Maven). Có lẽ ai đó có thể nhận xét về việc này có thực sự hoạt động với Eclipse + m2eclipse hay không.

Maven là một trong những công cụ mà bạn cần phải thực sự quyết định trước rằng bạn thích nó và muốn sử dụng nó, vì bạn sẽ dành khá nhiều thời gian để tìm hiểu nó, và đã đưa ra quyết định một lần và cho tất cả sẽ cho phép bạn bỏ qua tất cả các loại nghi ngờ trong khi học (vì bạn thích nó và muốn sử dụng nó)!

Các quy ước mạnh mẽ giúp đỡ ở nhiều nơi - như Hudson có thể làm nên điều kỳ diệu với các dự án Maven - nhưng ban đầu có thể khó thấy.

chỉnh sửa: Tính đến năm 2016, Maven là công cụ xây dựng Java duy nhất trong đó cả ba IDE chính đều có thể sử dụng các nguồn ngoài hộp. Nói cách khác, sử dụng maven làm cho bản dựng IDE của bạn không thể tin được. Điều này cho phép ví dụ như sử dụng cấu hình Netbeans ngay cả khi bạn thường làm việc trong nhật thực

Lợi thế của Maven so với kiến ​​là khá ít. Tôi cố gắng tóm tắt chúng ở đây.

Quy ước về cấu hình
Maven sử dụng một cách tiếp cận đặc biệt cho bố cục và khởi động dự án, giúp dễ dàng nhảy vào một dự án. Thông thường, nó chỉ mất lệnh checkount và lệnh maven để lấy các tạo phẩm của dự án.

Dự án mô đun hóa
dự án Các quy ước dự án đề xuất (hoặc tốt hơn, buộc) nhà phát triển phải mô đun hóa dự án. Thay vì một dự án nguyên khối, bạn thường bị buộc phải chia dự án của mình thành các thành phần phụ nhỏ hơn, giúp việc gỡ lỗi và quản lý cấu trúc dự án tổng thể dễ dàng hơn

Quản lý phụ thuộc và Vòng đời dự án
Nhìn chung, với cấu hình SCM tốt và kho lưu trữ nội bộ, việc quản lý phụ thuộc khá dễ dàng và bạn lại buộc phải suy nghĩ về Vòng đời dự án - phiên bản thành phần, quản lý phát hành, v.v. Một chút phức tạp hơn kiến ​​một cái gì đó, nhưng một lần nữa, một sự cải thiện về chất lượng của dự án.

Có chuyện gì với maven vậy?
Maven không dễ. Chu trình xây dựng (những gì được thực hiện và khi nào) không quá rõ ràng trong POM. Ngoài ra, một số vấn đề phát sinh với chất lượng của các thành phần và thiếu phụ thuộc trong kho công cộng.
Cách tiếp cận tốt nhất (với tôi) là có một kho lưu trữ nội bộ để lưu trữ (và lưu giữ) các phụ thuộc xung quanh và áp dụng để quản lý phát hành các thành phần. Đối với các dự án lớn hơn các dự án mẫu trong một cuốn sách, bạn sẽ cảm ơn maven trước hoặc sau

Maven có thể cung cấp lợi ích cho quá trình xây dựng của bạn bằng cách sử dụng các quy ước và thông lệ tiêu chuẩn để đẩy nhanh chu kỳ phát triển của bạn đồng thời giúp bạn đạt được tỷ lệ thành công cao hơn. Để có cái nhìn chi tiết hơn về cách Maven có thể giúp bạn trong quá trình phát triển của mình, vui lòng tham khảo Lợi ích của việc sử dụng Maven.

Maven là một công cụ quản lý dự án mạnh mẽ dựa trên POM (mô hình đối tượng dự án). Nó được sử dụng để xây dựng dự án, phụ thuộc và tài liệu. Nó đơn giản hóa quá trình xây dựng như ANT. Nhưng nó quá cao cấp hơn ANT. Maven giúp quản lý- Xây dựng, Tài liệu, Khôi phục, SCM, Phát hành, Phân phối. - Kho lưu trữ maven là một thư mục của tệp JAR được đóng gói với tệp pom.xml. Maven tìm kiếm các phụ thuộc trong kho.

Tôi chưa bao giờ đi qua điểm 2? Bạn có thể giải thích lý do tại sao bạn nghĩ rằng điều này ảnh hưởng đến việc triển khai theo bất kỳ cách nào. Nếu bất cứ điều gì maven cho phép bạn cấu trúc các dự án của mình theo cách được mô đun hóa thực sự cho phép sửa lỗi nóng cho các lỗi trong một tầng cụ thể và cho phép phát triển độc lập API từ phần còn lại của dự án.

Có thể là bạn đang cố gắng nhồi nhét mọi thứ vào một mô-đun duy nhất, trong trường hợp đó, vấn đề không thực sự xảy ra, mà là cách bạn đang sử dụng nó.

Điều này đáng lẽ phải là một bình luận, nhưng nó không phù hợp với độ dài bình luận, vì vậy tôi đã đăng nó như một câu trả lời.

Tất cả những lợi ích được đề cập trong các câu trả lời khác đều có thể đạt được bằng các phương tiện đơn giản hơn là sử dụng maven. Ví dụ, nếu bạn chưa quen với một dự án, dù sao bạn cũng sẽ dành nhiều thời gian hơn để tạo kiến ​​trúc dự án, tham gia các thành phần, mã hóa hơn là tải xuống các tệp và sao chép chúng vào thư mục lib. Nếu bạn có kinh nghiệm trong lĩnh vực của mình, thì bạn đã biết cách bắt đầu dự án với những thư viện nào. Tôi không thấy bất kỳ lợi ích nào của việc sử dụng maven, đặc biệt là khi nó gây ra nhiều vấn đề trong khi tự động thực hiện "quản lý phụ thuộc".

Tôi chỉ có kiến ​​thức trung cấp về maven, nhưng tôi nói với bạn, tôi đã thực hiện các dự án lớn (như ERP) mà không sử dụng maven.