Maven gây ấn tượng với tôi như một trường hợp của thứ gì đó được viết bởi một loạt những đứa trẻ tập lệnh c-shell trong quá khứ, những người nghĩ rằng autoconf đang dẫn đầu tự động hóa mã biên và không hiểu rằng mã đối tượng yêu cầu phải có môi trường đối tượng bất kỳ cách nào hiệu quả cho phát triển hoặc triển khai. Ant đã đủ tệ, nhưng Maven kết hợp tất cả các tính năng tồi tệ nhất của Ant và Ivy. Nó không tạo ra một môi trường đối tượng và nó không hoạt động tốt với các công cụ làm được.
Đơn giản, một môi trường đối tượng nên có tất cả các đối tượng lớp, tức là các đối tượng xác định loại đối tượng có sẵn cho hệ thống, tồn tại và luôn sẵn sàng. Từ đó, tôi có thể làm bất cứ điều gì tôi muốn, khởi tạo nhiều đối tượng của một lớp, thiết lập các trình tự và quy tắc khởi tạo khác nhau, v.v. Vì môi trường phải hoàn toàn trực tiếp, tôi không cầnmột công cụ xây dựng. Về mặt triển khai ứng dụng của tôi, không khó để môi trường chỉ cần loại bỏ tất cả các đối tượng lớp không bao giờ được tham chiếu bởi mã trong các không gian tên tạo nên ứng dụng của tôi. Người thu gom rác trong JVM gần như làm điều tương tự ngày nay. Tại thời điểm đó, tôi có một môi trường triển khai được tạo thành từ các đối tượng của tôi và tất cả các đối tượng (chủ yếu là các đối tượng lớp) mà các đối tượng của tôi tham chiếu, tức là ứng dụng của tôi và tất cả các phụ thuộc. Đây là cách máy ảo hoạt động. (rằng các máy ảo của chúng tôi được viết rất kém, chúng tôi cần chạy một máy ảo mùa xuân trên máy ảo Java trên máy ảo Linux trên máy ảo VMWare trên máy ảo Linux khác là một ví dụ khác về sự ngu ngốc của phát triển phần mềm). Khi các phần phụ thuộc được cập nhật, nó đủ đơn giản để môi trường nhắc nhà phát triển hợp nhất mã cũ của mình với các libs mới, hợp nhất mã bằng cách sử dụng libs mới xuống phiên bản cũ hơn hoặc giữ cả hai phiên bản. Việc nhắc nhở khuyến khích nhà phát triển thực hiện các sửa đổi nhỏ đôi khi cần thiết để tránh có hai mươi phiên bản của mọi thư viện, trong khi các công cụ như Maven che giấu sự thật rằng bạn có hai mươi phiên bản và dẫn đến tình trạng phồng rộp thời gian chạy phổ biến trong các ứng dụng Java.
Trong không gian phát triển Java, Eclipse đến gần nhất với việc trở thành một môi trường đối tượng thích hợp, mặc dù được cho là có rất nhiều plugin phá vỡ mô hình theo nhiều cách khác nhau. Hầu hết các lý do được đưa ra để sử dụng Maven đều sụp đổ khi được xem xét kỹ lưỡng.
Netbeans và Idea là những trình soạn thảo văn bản bị thổi phồng quá mức, không phải là môi trường đối tượng, nhưng nếu bạn muốn sử dụng các công cụ của họ cho một thứ gì đó không có trong hàng nghìn plugin Eclipse, cả hai đều có thể nhập và duy trì các dự án Eclipse, bản dựng của bạn sẽ rất chậm so với các nhà phát triển bằng Eclipse, nhưng sau đó, chúng sẽ chậm đến mức đó nếu chúng là các dự án Netbeans hoặc Idea thuần túy.
Không phải là một lý do nghiêm túc để sử dụng Maven.
Việc dễ dàng xuất / nhập cài đặt trong Eclipse (điều mà mọi nhóm nên làm trong bất kỳ IDE nào trong mọi trường hợp) khiến cho các cài đặt khác nhau trở nên vấn đề hơn là sự lười biếng của nhóm phát triển (hoặc một cuộc tranh cãi tôn giáo về khoảng trắng so với tab, lol) .
Một lần nữa, không phải là một lý do nghiêm túc để sử dụng Maven.
Môi trường đội? Chỉ cho tôi một nhóm chưa sử dụng kho lưu trữ như GIT hoặc SVN. Tại sao chúng ta cần phải sao chép cả chức năng và vấn đề bảo trì bằng cách thiết lập các đại diện Nexus?
Đó thực sự là một lý do chính đáng để KHÔNG sử dụng Maven.
Chạy một bản dựng máy chủ? Ý tưởng tuyệt vời, bây giờ, không nên bắt đầu bằng mã thực sự được đăng ký vào kho nguồn thay vì một bản dựng ngẫu nhiên xảy ra để được đẩy sang Nexus? Điều này dẫn đến một điểm chống lại Git, đặc biệt là Git với Maven. Vì trong Git, tôi không làm việc trên một chi nhánh, hãy thử nghiệm cục bộ, sau đó cam kết (một phần vì thử nghiệm cục bộ của tôi không chứng minh bản dựng máy chủ hoạt động do sự khác biệt trong cấu hình Maven trong Jenkins và Eclipse), tôi phải cam kết các thay đổi của mình đối với một nhánh khác để thấy rằng bản dựng Maven máy chủ không thành công, sau đó thực hiện một thay đổi khác để khắc phục sự cố, dẫn đến lịch sử nguồn không thể đọc được trong repo. Mã đã đăng ký ít nhất phải xây dựng và vượt qua các bài kiểm tra đơn vị, điều này nếu Git và Maven không có trong hình ảnh thì nên được đảm bảo.
Việc xuất một bản dựng không đầu từ Eclipse là điều không cần thiết nếu bạn thực sự quan tâm đến nó - tất cả những gì bạn cần là ant hoặc Gradle, bản dựng dành cho nhà phát triển đã được Eclipse duy trì và một vài lọ Eclipse (Eclipse sẽ xuất tất cả các tệp cần thiết cho một bản dựng không đầu sang một thư mục hoặc tệp zip hoặc ftp chúng vào máy chủ bản dựng). Các công cụ xây dựng máy chủ như Hudson / Jenkins có thể kéo mã cập nhật từ hầu hết các kho lưu trữ nguồn và gọi bất kỳ tập lệnh xây dựng nào, không có sự phụ thuộc vào Maven. Với Maven, bạn có thể buộc các nhà phát triển sử dụng một công cụ không phù hợp với bất kỳ ai ngoài các kỹ sư xây dựng (thời gian xây dựng lớn hơn, thậm chí sử dụng M2E, là đủ cho trường hợp đó được thực hiện) hoặc bạn sống với khả năng xây dựng máy chủ không hoạt động khá giống như việc xây dựng trạm làm việc, đó là vẫnđúng nếu bạn trải qua tất cả những rắc rối khi tích hợp cả hai bằng cách sử dụng rất nhiều plugin M2E. Dù bằng cách nào thì bạn cũng có được một bản dựng máy trạm chậm hơn và mỏng manh hơn vì lợi ích của một bản dựng máy chủ chậm và mỏng manh hơn. Trên mọi dự án dựa trên Maven mà tôi đã làm việc, tôi đã thấy các lỗi Hudson / Jenkins thoáng qua không hiển thị trong Eclipse trừ khi bạn đã cài đặt và định cấu hình đúng mọi plugin M2E có thể có, và hầu hết các nhà phát triển không bao giờ làm vậy.
Có vẻ như một lý do tuyệt vời khác để tránh Maven.
Điều đó không bao gồm một số vấn đề cơ bản hơn với Maven, chẳng hạn như không gian tên của nó phá vỡ không gian tên Java và không gian tên XML, đơn vị xây dựng (POM) của nó không liên quan đến bất kỳ thứ gì trong môi trường triển khai thực tế (hãy nghĩ về nó, khi bạn tách thông qua POM, những gì bạn thực sự đạt được trong sản phẩm hoàn chỉnh? Không có gì. Tất cả những gì nó đạt được là một cảm giác sai lầm rằng bạn đã tách các mối quan tâm và chức năng thành các đơn vị xây dựng khác nhau, tất cả đều chạynhư một đoạn mã nguyên khối); rắc rối của việc duy trì các tệp cấu hình phức tạp theo cách thủ công, điều này chỉ trở nên tồi tệ hơn nếu bạn tình cờ cần sử dụng OSGi hoặc một vùng chứa khác và phải duy trì các tệp cấu hình khác ảnh hưởng và bị ảnh hưởng bởi cấu hình Maven với rất ít cảm giác rõ ràng đối với nó; các vấn đề gây ra do cố gắng chạy các bài kiểm tra đơn vị mà không có môi trường đầy đủ để mã thực thi trong đó; vô số phiên bản không chỉ của các phụ thuộc mà còn của các plugin cụ thể của Maven (tôi thực sự đã thấy địa ngục JAR trong chính bản dựng của Maven , nơi nhiều plugin Maven đang sử dụng các phụ thuộc xung đột - một trong những vấn đề Maven phải giải quyết .
Có, bạn có thể xây dựng mã đối tượng với Maven. Bạn cũng có thể viết mã đối tượng thuần túy bằng C hoặc thậm chí là trình hợp dịch, nhưng tôi không biết tại sao bạn lại muốn.
Lý do tốt nhất để tránh Maven là số lượng công việc phi thường cần thiết để hủy bỏ một tập hợp các dự án khi bạn phát ốm vì tất cả các vấn đề đã nêu ở trên (và nhiều vấn đề khác không được đề cập).
Tư duy, kế thừa từ phát triển C, rằng chu trình phát triển bao gồm viết mã, biên dịch, lắp ráp, xây dựng, triển khai, kiểm tra, làm lại, đã lỗi thời trong môi trường đối tượng. Tại một thời điểm nào đó, chúng tôi cần nói với tất cả những người có suy nghĩ này rằng họ cần học lại cách phát triển, giai đoạn. Làm như vậy sẽ loại bỏ mọi nhu cầu về Maven, Git và một loạt các công cụ khác không làm gì khác ngoài việc lãng phí thời gian.
Việc phát triển đối tượng nên được thực hiện trong môi trường đối tượng trực tiếp, nơi một thay đổi mã được kiểm tra khi nó được lưu vì đối tượng sửa đổi đang hoạt động. Việc triển khai chỉ nên loại bỏ các đồ tạo tác phát triển khỏi môi trường đó, tạo một thời gian chạy có mọi thứ được ứng dụng đang chạy sử dụng trong quá trình phát triển và thử nghiệm.
Tôi hiện đang xử lý sự cố do tạo các hội đồng triển khai cho ứng dụng OSGi bằng cách sử dụng plugin maven-assembly. Ứng dụng hoạt động hoàn hảo trong môi trường Eclipse, môi trường này triển khai tất cả các thay đổi mã vào một vùng chứa OSGi đang chạy trong môi trường. Tuy nhiên, cấu hình không tồn tại nguyên vẹn thông qua quá trình lắp ráp maven, mặc dù có một kỹ sư xây dựng / cấu hình rất tốt với công việc duy nhất là hoàn thành quá trình đó. Nếu chúng tôi loại bỏ Maven (hiện tại rất khó do số lượng mã, nhưng có thể) và sử dụng plugin BNDTOOLS Eclipse, chúng tôi có thể chỉ cần xuất bản dựng Eclipse dưới dạng bản dựng không đầu Ant hoặc Gradle (lưu ý, các nhà phát triển OSGi viết BND và BNDTOOLS khônghỗ trợ Maven, và vì lý do tốt, plugin Maven được viết bởi các nhà phát triển Felix người thân sử dụng Netbeans và Maven, và không có môi trường sống khác hơn ở phần cuối của chu kỳ triển khai), nơi cả hai công cụ thiết lập cùng một môi trường như Eclipse, mà không có các đối tượng GUI chỉ dành cho các nhà phát triển. Kết quả sẽ là một cấu hình và bản dựng giống hệt nhau để triển khai. Điều này sẽ dễ dàng tiết kiệm 2-3 giờ mỗi ngày cho mỗi nhà phát triển hiện đang xem các bản dựng Maven hoặc M2E chậm và giải phóng kỹ sư cấu hình / xây dựng để thực hiện thêm thử nghiệm ứng dụng trên máy chủ triển khai.
Vượt qua tư duy viết / biên dịch / lắp ráp / xây dựng / triển khai / thử nghiệm là trở ngại lớn duy nhất. Giả vờ bạn đang viết mã trên thiết bị đầu cuối VT100 năm 1979 thay vì một máy hiện đại không khiến bạn trở thành một nhà phát triển 'thực sự', nó chỉ chứng tỏ rằng các phương pháp của bạn đã lỗi thời 35 năm.
Trong số các nhà phát triển trong nhóm, không ai trong số những người khác hiểu đúng về môi trường đối tượng trực tiếp như Eclipse đủ để làm cho nó hoạt động như một môi trường trực tiếp với M2E và OSGi, và họ là những nhà phát triển hàng đầu, họ chưa được tiếp xúc với nó do trước sự phổ biến của các công cụ phát triển dòng lệnh lỗi thời. Họ chỉ nhận ra rằng có thể làm như vậy khi chúng tôi lập trình ghép nối để giải quyết vấn đề cấu hình và tôi đang chia sẻ màn hình của mình, khiến một trong những thành viên khác trong nhóm thốt lên " đó là Làm thế nào bạn viết mã nhanh như vậy ", khi anh ấy thấy mã của tôi thay đổi ngay lập tức tự kiểm tra trong vùng chứa OSGi nền. Tôi có thể sử dụng bash shell khi cần, chẳng hạn như khi tôi xem nhật ký trên máy chủ từ xa, trong thực tế là tôi làm như vậy khá hiệu quả, chính xác để tôi có thể thoát ra khỏi môi trường đó càng nhanh càng tốt và quay trở lại thế kỷ 21.