Tại sao Maven lại có một rep tệ như vậy? [đóng cửa]

Có rất nhiều lời bàn tán trên mạng về việc Maven tệ như thế nào. Tôi đã sử dụng một số tính năng của Maven trong vài năm nay và lợi ích quan trọng nhất theo quan điểm của tôi là quản lý sự phụ thuộc.

Tài liệu về Maven ít hơn đầy đủ, nhưng nói chung khi tôi cần hoàn thành điều gì đó, tôi tìm ra nó một lần và sau đó nó hoạt động (ví dụ: khi tôi thực hiện ký tên vào các lọ). Tôi không nghĩ rằng Maven là tuyệt vời, nhưng nó giải quyết được một số vấn đề mà nếu không có nó sẽ là một nỗi đau thực sự.

Vậy tại sao Maven lại có một rep tệ như vậy và tôi có thể mong đợi những vấn đề gì với Maven trong tương lai? Có thể có nhiều lựa chọn thay thế tốt hơn mà tôi không biết? (Ví dụ, tôi chưa bao giờ nhìn chi tiết Ivy.)

LƯU Ý: Đây không phải là một nỗ lực để gây ra một cuộc tranh cãi. Đó là một nỗ lực để xóa FUD.

Tôi đã nhìn vào maven khoảng sáu tháng trước. Chúng tôi đang bắt đầu một dự án mới và không có bất kỳ di sản nào để hỗ trợ. Mà nói:

• Maven là tất cả hoặc không có gì. Hoặc ít nhất là theo như tôi có thể nói từ tài liệu. Bạn không thể dễ dàng sử dụng maven để thay thế kiến, và dần dần áp dụng các tính năng nâng cao hơn.
• Theo tài liệu, Maven là hạnh phúc siêu việt biến tất cả những giấc mơ ngông cuồng nhất của bạn thành hiện thực. Bạn chỉ cần thiền định về sách hướng dẫn trong 10 năm trước khi bạn trở nên chứng ngộ.
• Maven làm cho quá trình xây dựng của bạn phụ thuộc vào kết nối mạng của bạn.
• Maven có thông báo lỗi vô ích. So sánh "Mục tiêu x không tồn tại trong dự án y" của kiến ​​với "Tác vụ không hợp lệ 'chạy' của mvn: bạn phải chỉ định giai đoạn vòng đời hợp lệ hoặc mục tiêu trong định dạng plugin: mục tiêu hoặc pluginGroupId: pluginArtifactId: pluginVersion: mục tiêu" Rất hữu ích, nó gợi ý tôi chạy mvn với -e để biết thêm thông tin, có nghĩa là nó sẽ in cùng một thông báo, sau đó là một dấu vết ngăn xếp cho BuildFailureException.

Phần lớn sự không thích của tôi đối với maven có thể được giải thích bằng đoạn trích sau đây từ Better Builds with Maven:

Khi ai đó muốn biết Maven là gì, họ thường hỏi "Maven chính xác là gì?", Và họ mong đợi một câu trả lời ngắn gọn, hợp lý. “Chà, nó là một công cụ xây dựng hay một khuôn khổ viết kịch bản” Maven nói nhiều hơn ba từ nhàm chán, lôi cuốn. Nó là sự kết hợp của các ý tưởng, tiêu chuẩn và phần mềm, và không thể chắt lọc định nghĩa của Maven để chỉ đơn giản là những thứ âm thanh đã được tiêu hóa. Những ý tưởng cách mạng thường khó truyền đạt bằng lời.

Đề xuất của tôi: nếu bạn không thể truyền đạt ý tưởng bằng lời, bạn không nên cố gắng viết một cuốn sách về chủ đề này, bởi vì tôi sẽ không tiếp thu ý tưởng bằng thần giao cách cảm.

• Nó áp đặt cấu trúc cứng nhắc cho bạn ngay từ đầu.
• Nó dựa trên XML nên khó đọc như ANT.
• Báo cáo lỗi của nó không rõ ràng và khiến bạn bị mắc kẹt khi mọi thứ diễn ra không như ý muốn.
• Các tài liệu là nghèo nàn.
• Nó làm cho những điều khó khăn trở nên dễ dàng và những điều đơn giản trở nên khó khăn.
• Mất quá nhiều thời gian để duy trì một môi trường xây dựng Maven, điều này làm mất đi quan điểm của việc có một hệ thống xây dựng toàn hót.
• Phải mất một thời gian dài để biết rằng bạn đã tìm thấy lỗi trong maven và không phải cấu hình sai. Và những con bọ vẫn tồn tại, và ở những nơi đáng ngạc nhiên.
• Nó hứa hẹn nhiều nhưng lại phản bội bạn như một người yêu xinh đẹp và quyến rũ nhưng lại lạnh lùng và lôi cuốn về mặt tình cảm.

Tôi chắc chắn đã từng buồn và rên rỉ về maven trong quá khứ. Nhưng bây giờ, tôi sẽ không thể thiếu nó. Tôi cảm thấy rằng lợi ích vượt xa mọi vấn đề. Chủ yếu:

• Cấu trúc dự án chuẩn hóa.
  • Đưa ra một nhà phát triển mới tham gia một dự án:
    • Khi bạn nói đó là một dự án Maven, thì nhà phát triển biết bố cục dự án và cách xây dựng và đóng gói dự án
    • Khi bạn nói đó là một dự án Ant, thì nhà phát triển sẽ phải đợi bạn giải thích thêm hoặc sẽ phải xem qua build.xml để tìm hiểu mọi thứ.
  • Tất nhiên, luôn có thể áp đặt tiêu chuẩn toàn công ty với Ant nhưng tôi nghĩ thường xuyên hơn không, bạn sẽ phát minh lại bánh xe tục ngữ.
• Quản lý sự phụ thuộc.
  • Không chỉ với các thư viện bên ngoài mà còn với các thư viện / mô-đun bên trong. Đảm bảo sử dụng máy chủ proxy của kho lưu trữ Maven như Nexus hoặc Artifactory .
  • Có thể thực hiện một số điều này với Ivy . Trên thực tế, nếu tất cả những gì bạn cần là quản lý sự phụ thuộc, thì có lẽ bạn nên sử dụng Ivy.
• Đặc biệt là trong một dự án. Tôi thấy việc chia nhỏ các dự án nhỏ khá hữu ích và maven xử lý tốt điều này. Nó khó hơn nhiều với kiến.
• Chuẩn quản lý vật (đặc biệt là kết hợp với mối quan hệ hoặc artifactory )
• Plugin phát hành thật tuyệt vời.
• Tích hợp Eclipse & NetBeans khá tốt.
• Tích hợp với hudson là tuyệt vời. Đặc biệt là đồ thị xu hướng cho những thứ như findbugs.
• Đó là một điểm nhỏ, nhưng thực tế là maven nhúng các chi tiết như số phiên bản bên trong jar hoặc war (không chỉ trong tên tệp) theo mặc định là rất hữu ích.

Nhược điểm đối với tôi chủ yếu là:

• Dòng lệnh khá vô ích. Điều này khiến tôi mất rất nhiều thời gian để bắt đầu.
• Định dạng XML rất dài dòng. Tôi có thể hiểu tại sao nó được thực hiện theo cách đó, nhưng vẫn còn là một nỗi đau khi đọc.
  • Điều đó nói rằng, nó có một XSD để dễ dàng chỉnh sửa trong IDE.
• Rất khó để làm cho đầu của bạn xoay quanh nó ngay từ đầu. Ví dụ như những thứ như vòng đời.
  • Tuy nhiên, hướng dẫn cuối cùng về maven là một phần giới thiệu tốt.

Tôi thực sự tin rằng việc dành một chút thời gian để làm quen với maven là đáng giá.

Kinh nghiệm thực tế của tôi từ hai dự án lớn là chúng tôi đã dành 1000 - 1500 giờ cho mỗi dự án cho các vấn đề liên quan đến maven, không bao gồm 500 giờ nỗ lực chuyển từ maven 1 sang maven 2.

Kể từ đó, tôi phải nói rằng tôi cực kỳ ghét maven. Tôi đang cảm thấy thất vọng khi nghĩ về nó.

Tích hợp Eclipse thật tệ. (Ví dụ: chúng tôi gặp vô vàn rắc rối với việc tạo mã, trong đó eclipse không đồng bộ với mã đã tạo và yêu cầu xây dựng lại hoàn toàn, khá thường xuyên. Nguyên nhân là do cả maven và eclipse, nhưng eclipse hữu ích hơn maven và nói emacs, vì vậy nhật thực ở lại và maven phải đi.)

Chúng tôi có rất nhiều phụ thuộc và khi chúng tôi phát hiện ra, các lỗi cú pháp thực sự được gửi đến kho lưu trữ maven công khai khá thường xuyên, điều này có thể làm hỏng hàng giờ quý giá của bạn. Mỗi tuần. Cách giải quyết là có một proxy hoặc kho lưu trữ được quản lý cục bộ và điều đó cũng mất khá nhiều thời gian để làm đúng.

Cấu trúc dự án Mavens không thực sự phù hợp để phát triển với Eclipse, và thời gian xây dựng trong eclipse tăng lên.

Một ảnh hưởng của vấn đề tạo và đồng bộ mã, chúng tôi phải xây dựng lại từ bản nháp khá thường xuyên, giảm chu kỳ mã / biên dịch / thử nghiệm của bạn thành một chu trình biên dịch vô tận / websurf / sleep / die / code-cycle, đưa bạn trở lại ngay những năm 90 và Thời gian biên dịch 40 phút.

Lý do duy nhất cho maven là giải pháp phụ thuộc, nhưng tôi muốn làm điều đó một lần, không phải trong mọi bản dựng.

Tóm lại, maven ở xa KISS nhất có thể. Ngoài ra, những người ủng hộ có xu hướng trở thành kiểu người ăn mừng nhiều hơn vào ngày sinh nhật của họ khi tuổi của họ là số nguyên tố. Hãy bình chọn tôi xuống :-)

Maven rất tuyệt. Lý do cho danh tiếng của nó có liên quan đến đường cong học tập dốc, theo ý kiến ​​của tôi. (mà cuối cùng tôi cũng gần vượt qua được)

Tài liệu này hơi khó để lướt qua, đơn giản vì có cảm giác như có rất nhiều văn bản và những điều mới để hiểu trước khi nó bắt đầu có ý nghĩa. Tôi nói rằng thời gian là tất cả những gì cần thiết để Maven được ca ngợi rộng rãi hơn.

Bởi vì Maven là một thiết bị để giảm những người đàn ông trưởng thành xuống thổn thức hàng loạt nỗi kinh hoàng tuyệt đối.

Ưu điểm:

• Quản lý sự phụ thuộc. Trong vài năm rồi, tôi và đồng nghiệp không tải xuống và quản lý các phần phụ thuộc theo cách thủ công. Đây là một tiết kiệm thời gian rất lớn.
• IDE-độc lập. Hóa ra, tất cả các IDE chính, Eclipse, IDEA và NetBeans đều có hỗ trợ tốt cho các dự án Maven để các nhà phát triển của chúng tôi không bị khóa vào một IDE cụ thể.
• Dòng lệnh. Với Maven, việc hỗ trợ đồng thời IDE và các cấu hình dòng lệnh rất đơn giản, điều này rất tốt cho việc tích hợp liên tục.

Nhược điểm:

• Phải đầu tư vào việc học Maven. Vâng, phải làm điều đó. Tin tốt, không phải ai trong đội cũng phải học.
• Tài liệu. Từng là một vấn đề, bây giờ nhờ Sonatype và cuốn sách của họ ( http://www.sonatype.com/products/maven/documentation/book-defguide ), tình hình đã tốt hơn nhiều.
• Sự cứng nhắc. Đôi khi thật khó khăn và khó chịu khi làm mọi thứ theo cách bạn muốn. Lời khuyên của tôi là không nên chiến đấu và bắt Maven làm những điều nó làm tốt nhất, xây dựng đơn giản hoặc khi có sẵn một võ đường ổn định. Trong các trường hợp khác, chúng tôi bỏ ra ngoài và thực hiện các công việc bằng các chương trình của Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ). Yêu thích cá nhân của tôi là Groovy plugun ( http://groovy.codehaus.org/GMaven ).

Cuộc thi:

• Ant: không có quản lý phụ thuộc. Giai đoạn = Stage.
• Ivy: vẫn kém trưởng thành hơn Maven (không phải là sau này cũng không có những điều kỳ quặc đó). Gần như cùng một bộ tính năng, vì vậy không có lý do thuyết phục nào để di chuyển. Tôi đã cố gắng thử nhiều lần; tất cả đều không thành công.

Điểm mấu chốt: tất cả các dự án của chúng tôi đều được thực hiện với Maven trong vài năm.

Tôi nghĩ nó có tiếng xấu với những người có những dự án đơn giản nhất và phức tạp nhất.

Nếu bạn đang xây dựng một WAR từ một cơ sở mã duy nhất, nó buộc bạn phải di chuyển cấu trúc dự án của mình xung quanh và liệt kê thủ công hai trong ba lọ vào tệp POM.

Nếu bạn đang xây dựng một EAR từ tập hợp chín nguyên mẫu tệp EAR với một số kết hợp của năm tệp WAR, ba EJB và 17 công cụ khác, các lọ phụ thuộc và cấu hình yêu cầu điều chỉnh tệp MANIFEST.MF và XML trong các tài nguyên hiện có trong quá trình xây dựng cuối cùng; thì Maven có thể quá hạn chế. Một dự án như vậy sẽ trở thành một mớ hỗn độn của các cấu hình, tệp thuộc tính lồng nhau phức tạp và việc sử dụng sai mục tiêu xây dựng Maven và chỉ định Bộ phân loại.

Vì vậy, nếu bạn đang ở dưới cùng của đường cong phức tạp 10%, thì mức độ quá mức cần thiết của nó. Ở 10% trên cùng của đường cong đó, bạn đang mặc một chiếc áo khoác bó.

Maven tăng trưởng là do nó hoạt động tốt cho 80% ở giữa

Kinh nghiệm của tôi lặp lại sự thất vọng của nhiều bài viết ở đây. Vấn đề với Maven là nó bao bọc và che giấu các chi tiết của quản lý bản dựng để tìm kiếm sự tốt đẹp tự động cuối cùng. Điều này khiến bạn gần như bất lực nếu nó bị vỡ.

Kinh nghiệm của tôi là bất kỳ vấn đề nào với maven đều nhanh chóng biến thành một cuộc săn bắn tỉa kéo dài nhiều giờ thông qua mạng các tệp xml lồng nhau, trong một trải nghiệm tương tự như viêm tủy răng.

Tôi cũng đã từng làm việc trong các cửa hàng phụ thuộc rất nhiều vào Maven, những người thích nó (những người thích nó với khía cạnh "nhấn một nút, hoàn thành tất cả") không hiểu điều đó. Các bản dựng maven có hàng triệu mục tiêu tự động, tôi chắc chắn sẽ hữu ích nếu tôi muốn dành hàng giờ để đọc qua những gì họ đã làm. 2 mục tiêu tốt hơn hoạt động mà bạn hoàn toàn hiểu.

cảnh báo: lần cuối làm việc với Maven cách đây 2 năm, bây giờ có thể tốt hơn.

Giống như Glenn, tôi không nghĩ Maven có một rep tệ mà là một rep hỗn hợp. Tôi đã làm việc độc quyền trong 6 tháng để cố gắng chuyển một dự án dự án khá lớn sang Maven và nó cho thấy rõ ràng các giới hạn của công cụ.

Theo kinh nghiệm của tôi, Maven tốt cho:

• quản lý phụ thuộc bên ngoài
• quản lý tập trung bản dựng (kế thừa pom)
• rất nhiều plugin cho nhiều thứ
• tích hợp rất tốt với các công cụ tích hợp liên tục
• khả năng báo cáo rất tốt (FindBugs, PMD, Checkstyle, Javadoc, ...)

Và nó có một số vấn đề với:

• tất cả hoặc không có cách tiếp cận nào (khó chuyển từ từ sang Maven)
• phụ thuộc phức hợp, phụ thuộc liên mô-đun
• phụ thuộc chu kỳ (tôi biết, thiết kế tồi, nhưng chúng tôi không thể sửa chữa 5 năm của nhà phát triển ...)
• mạch lạc (phạm vi phiên bản không hoạt động giống nhau ở mọi nơi)
• lỗi (một lần nữa với phạm vi phiên bản)
• các bản dựng có thể tái tạo (trừ khi bạn sửa số phiên bản của tất cả các plugin, bạn không thể chắc chắn rằng mình sẽ nhận được cùng một bản dựng sau 6 tháng)
• thiếu tài liệu (tài liệu khá tốt cho những điều cơ bản, nhưng không có nhiều ví dụ về cách xử lý các dự án lớn)

Để đưa ra một số bối cảnh, có khoảng 30 nhà phát triển đang làm việc trong dự án này và dự án đã tồn tại hơn 5 năm, vì vậy: rất nhiều di sản, nhiều quy trình đã có, rất nhiều công cụ độc quyền tùy chỉnh đã có sẵn. Chúng tôi quyết định thử chuyển sang Maven vì chi phí duy trì các công cụ độc quyền của chúng tôi ngày càng cao.

Tôi muốn phản đối một số khiếu nại được đưa ra trong diễn đàn này:

Maven là tất cả hoặc không có gì. Hoặc ít nhất là theo như tôi có thể nói từ tài liệu. Bạn không thể dễ dàng sử dụng maven để thay thế kiến, và dần dần áp dụng các tính năng nâng cao hơn.

Điều này không đúng. Chiến thắng lớn của Maven là sử dụng nó để quản lý sự phụ thuộc của bạn một cách hợp lý và nếu bạn muốn làm điều đó trong maven và làm mọi thứ khác trong kiến, bạn có thể. Đây là cách thực hiện:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Bây giờ bạn có một đối tượng classpath có tên 'maven.classpath' chứa tất cả các phụ thuộc maven được xác định trong tệp pom. Tất cả những gì bạn cần là đặt jar nhiệm vụ kiến ​​maven vào thư mục lib của kiến.

Maven làm cho quá trình xây dựng của bạn phụ thuộc vào kết nối mạng của bạn.

Quá trình tìm nạp plugin và phụ thuộc mặc định phụ thuộc vào kết nối mạng, có, nhưng chỉ dành cho bản dựng ban đầu (hoặc nếu bạn thay đổi các phần phụ thuộc hoặc plugin đang sử dụng). Sau đó, tất cả các lọ được lưu vào bộ nhớ cache cục bộ. Và nếu bạn muốn buộc không có kết nối mạng, bạn có thể yêu cầu maven sử dụng chế độ ngoại tuyến.

Nó áp đặt cấu trúc cứng nhắc cho bạn ngay từ đầu.

Nó không rõ ràng nếu điều này đề cập đến định dạng tệp hoặc vấn đề 'quy ước so với cấu hình'. Đối với thứ hai, có rất nhiều mặc định vô hình như vị trí dự kiến ​​của tài nguyên và tệp nguồn java hoặc khả năng tương thích của nguồn. Nhưng đây không phải là sự cứng nhắc, nó đặt các giá trị mặc định hợp lý cho bạn để bạn không cần phải xác định chúng một cách rõ ràng. Tất cả các cài đặt có thể bị ghi đè khá dễ dàng (mặc dù đối với người mới bắt đầu, có thể khó tìm thấy trong tài liệu cách thay đổi một số thứ nhất định).

Nếu bạn đang nói về định dạng tệp, thì điều đó sẽ được đề cập trong phần trả lời của phần tiếp theo ...

Nó dựa trên XML nên khó đọc như ANT.

Trước hết, tôi không hiểu làm thế nào bạn có thể phàn nàn rằng một số khía cạnh của thứ gì đó 'Không tốt hơn con kiến' như một lời biện minh cho việc nó có một đại diện tồi. Thứ hai, trong khi nó vẫn XML, định dạng của XML được nhiều hơn xác định. Hơn nữa, bởi vì nó được định nghĩa như vậy nên việc tạo một trình soạn thảo khách hàng dày hợp lý cho POM dễ dàng hơn rất nhiều. Tôi đã thấy các trang viết kịch bản xây dựng kiến ​​dài ngoằng khắp nơi. Bất kỳ trình biên tập kịch bản xây dựng kiến ​​nào sẽ không làm cho điều đó trở nên ngon miệng hơn, chỉ là một danh sách dài các nhiệm vụ được kết nối với nhau được trình bày theo một cách hơi khác.

Phải nói rằng có một vài lời phàn nàn mà tôi đã thấy ở đây rằng có hoặc có một số tội lỗi, bản chất lớn nhất

• Tài liệu kém / thiếu
• Các bản dựng có thể tái tạo
• Tích hợp Eclipse không tốt
• Lỗi

Mà phản hồi của tôi là gấp đôi. Đầu tiên, Maven là một công cụ trẻ hơn nhiều so với Ant or Make, vì vậy bạn phải mong đợi rằng nó sẽ mất thời gian để đạt được mức độ trưởng thành của các ứng dụng đó. Thứ hai là, nếu bạn không thích nó, hãy sửa chữa nó . Nó là một dự án mã nguồn mở và việc sử dụng nó và sau đó phàn nàn về điều gì đó mà bất kỳ ai cũng có thể giúp tôi giải quyết có vẻ khá bình thường đối với tôi. Bạn không thích tài liệu? Đóng góp vào nó để làm cho nó rõ ràng hơn, đầy đủ hơn hoặc dễ tiếp cận hơn cho người mới bắt đầu.

Sự cố bản dựng có thể tái tạo được chia thành hai vấn đề, phạm vi phiên bản và cập nhật plugin maven tự động. Đối với các bản nâng cấp của plugin, trừ khi bạn đảm bảo rằng khi bạn xây dựng lại dự án một năm sau rằng bạn đang sử dụng cùng một phiên bản JDK và Ant chính xác, thì đây chỉ là vấn đề tương tự với một tên khác. Đối với phạm vi phiên bản, tôi khuyên bạn nên làm việc trên một plugin sẽ tạo ra một bản pom tạm thời với các phiên bản bị khóa cho tất cả các phụ thuộc trực tiếp và bắc cầu và biến nó thành một phần của vòng đời phát hành maven. Bằng cách đó, các bản dựng bản phát hành của bạn luôn là mô tả chính xác của tất cả các phần phụ thuộc.

Nó xứng đáng với danh tiếng mà nó có được. Không phải ai cũng cần cấu trúc cứng nhắc mà các nhà phát triển của Maven cho rằng phù hợp cho mọi dự án. Nó rất không linh hoạt. Và 'Pro' đối với nhiều người, quản lý sự phụ thuộc, IMHO là 'con' lớn nhất của nó. Tôi hoàn toàn không thoải mái với việc maven tải xuống các lọ từ mạng và mất ngủ vì không tương thích (vâng, chế độ ngoại tuyến tồn tại, nhưng tại sao tôi phải có tất cả hàng trăm tệp xml và tổng kiểm tra đó). Tôi quyết định thư viện nào tôi sử dụng và nhiều dự án có mối quan tâm nghiêm trọng về việc xây dựng phụ thuộc vào kết nối mạng.

Tệ hơn nữa, khi mọi thứ không hoạt động, bạn hoàn toàn bị mất. Tài liệu tệ, cộng đồng là không có cơ sở.

Một năm sau, tôi muốn cập nhật điều này: Tôi không còn quan điểm này nữa về cộng đồng Maven. Tôi sẽ không viết câu trả lời này nếu câu hỏi được hỏi ngày hôm nay. Tôi sẽ thêm ý kiến ​​hiện tại của mình như một câu trả lời riêng.

Đây là một câu trả lời rất chủ quan, nhưng câu hỏi là về ý kiến, vì vậy ...

Tôi thích Maven, và càng ngày càng thích nó. Tuy nhiên, có một điều ảnh hưởng đến cảm nhận của tôi về nó: cộng đồng maven chủ yếu tập trung xung quanh Sonatype ("công ty maven", đó là nơi nhiều Maven honchos đang làm việc) và Sonatype đang đẩy mạnh các sản phẩm của công ty mình trên cộng đồng.

Ví dụ: Luồng twitter "Maven Book" liên kết đến phần giới thiệu được cho là về quản lý kho lưu trữ .

Rất tiếc, "phần giới thiệu" đó là một nửa thông tin, một nửa quảng cáo chiêu hàng dành cho Nexus. Câu đố vui: có bất kỳ trình quản lý repo nào khác ngoài Nexus và Nexus Pro không? Ngoài ra, điều đó có liên quan gì đến Sách Maven nguồn mở được cho là? Ồ, đúng rồi, chương về quản lý kho lưu trữ đã được tách thành một cuốn sách riêng ... về Nexus. Huh. Nếu tôi đóng góp cho cuốn sách Maven, tôi có nhận được phí giới thiệu nếu tôi làm tăng doanh số bán Nexus không?

Hãy tưởng tượng nếu bạn đang tham gia một diễn đàn phát triển Java và rõ ràng là các nhân viên của Sun thảo luận về Java sẽ nắm bắt mọi cơ hội có thể để nói về NetBeans và "NetBeans Pro". Sau một thời gian, nó mất đi một số cảm giác cộng đồng. Tôi chưa bao giờ có trải nghiệm như vậy với Ant.

Sau khi nói tất cả những điều đó, tôi nghĩ rằng Maven là một hệ thống rất thú vị và hữu ích (tôi không gọi nó là một công cụ, giống như Ant, nói rộng hơn là Maven) để cấu hình phát triển phần mềm và quản lý xây dựng. Quản lý sự phụ thuộc đôi khi là một may mắn và một lời nguyền, nhưng nó mới mẻ - và chắc chắn không phải là lợi thế duy nhất mà Maven mang lại. Có lẽ tôi đang phản ứng hơi quá mạnh với đồng shilling của Sonatype, nhưng theo ý kiến ​​của tôi thì điều đó gây tổn hại cho Maven. Tôi không biết nếu ý kiến ​​này được chia sẻ bởi ai khác.

Tôi nghĩ Maven có một bản rap tệ vì nó áp đặt cấu trúc vào dự án của bạn, trong khi các công cụ khác như Ant cho phép bạn hoàn toàn xác định cấu trúc theo bất kỳ cách nào bạn muốn. Cũng đồng ý rằng tài liệu không tốt, nhưng tôi nghĩ chủ yếu phần rap tệ mà Maven nhận được là do mọi người đã quá quen với Ant.

Quá nhiều ma thuật.

Bởi vì những người không hài lòng sẽ phàn nàn trong khi những người hài lòng không nói rằng họ hài lòng. Quan điểm của tôi là có nhiều người dùng maven hài lòng hơn là không hài lòng nhưng càng về sau càng gây ồn ào. Đây cũng là một mẫu phổ biến trong cuộc sống thực (ISP, nhà cung cấp dịch vụ điện thoại, phương tiện giao thông, v.v.).

Vấn đề quan trọng nhất đối với tôi là Maven, khi không được định cấu hình đúng cách, có thể không tạo ra các bản dựng có thể lặp lại, do:

• kho lưu trữ từ xa không đáng tin cậy;
• phụ thuộc vào các plugin và thư viện có phiên bản SNAPSHOT hoặc không có phiên bản.

Đối chiếu điều này với một công trình kiến ​​- mặc dù dài dòng và IMO mệt mỏi - hoạt động vì tất cả các lọ đều được kiểm tra cục bộ.

Phần tốt là các vấn đề có thể giải quyết được:

• sử dụng kho lưu trữ maven của riêng bạn, điều này đã trở nên đơn giản, tôi đang sử dụng Archiva với kết quả tốt;
• luôn phiên bản đúng các phụ thuộc của bạn. Maven đã bắt đầu khóa các phiên bản plugin trong super-POM bắt đầu với 2.0.8 hoặc 2.0.9 và tất cả các phụ thuộc của bạn phải nằm trên các phiên bản đã phát hành.

ý tưởng tuyệt vời - triển khai kém.

Tôi đã chuyển một dự án từ Ant sang Maven gần đây. Cuối cùng, nó hoạt động tốt, nhưng tôi phải sử dụng hai phiên bản khác nhau của maven-assembly-plugin và maven-jar-plugin trong cùng một bản pom (có hai cấu hình) vì những gì hoạt động trong một phiên bản này đã bị hỏng trong một phiên bản khác.

Nên khá là đau đầu. Tài liệu không phải lúc nào cũng tuyệt vời nhưng tôi phải thừa nhận rằng nó tương đối dễ dàng để tìm câu trả lời trên google.

đảm bảo rằng bạn luôn chỉ định các phiên bản của trình cắm bạn sử dụng. Đừng mong đợi rằng phiên bản mới sẽ tương thích ngược.

Tôi nghĩ rằng tranh cãi xuất phát từ thực tế là maven vẫn tiến hóa và quá trình này đôi khi gây đau đớn.

Trân trọng

v.

Tôi thích maven. Tôi đã sử dụng nó từ trước phiên bản 1.0. Đó là một công cụ mạnh mẽ mà về số dư đã giúp tôi tiết kiệm đáng kể thời gian và cải thiện cơ sở hạ tầng phát triển của tôi. Nhưng tôi có thể hiểu được sự thất vọng của một số người. Tôi thấy có 3 loại thất vọng:

1. trong đó nguyên nhân là mối quan tâm thực sự (ví dụ: POM dài dòng, thiếu tài liệu),
2. một số là thông tin sai lệch (ví dụ: "bạn phải có kết nối internet để xây dựng" - không đúng - không đúng, điều này có thể tránh được),
3. một số trong số đó được trút vào maven nhưng thực sự có người khác là đáng trách ("không bắn người đưa tin").

Đối với trường hợp đầu tiên, các vấn đề thực sự - tốt, chắc chắn là có vấn đề, POM dài dòng, tài liệu hướng dẫn có thể tốt hơn. Tuy nhiên, mặc dù vậy, có thể đạt được kết quả tốt với maven trong thời gian nhanh chóng. Tôi co rúm người lại mỗi khi nhận được một dự án được xây dựng bằng kiến ​​và cố gắng nhập nó vào IDE của mình. Có thể mất nhiều thời gian để thiết lập cấu trúc thư mục. với maven, đó chỉ là trường hợp mở tệp POM trong IDE.

Đối với trường hợp thứ hai, Maven rất phức tạp và sự hiểu lầm là điều thường thấy. Nếu maven 3 có thể tìm ra cách giải quyết sự phức tạp này (hoặc thậm chí là sự phức tạp được nhận thức) thì điều đó sẽ tốt. maven thực sự mất một khoản đầu tư đáng kể, nhưng theo kinh nghiệm của tôi, khoản đầu tư sẽ tự trả nhanh chóng.

Đối với điểm cuối cùng, tôi nghĩ rằng sự hấp dẫn về các phụ thuộc bắc cầu của maven có lẽ là ví dụ được biết đến nhiều nhất.

Phụ thuộc bắc cầu là bản chất của phần mềm thực sử dụng tái sử dụng. Windows DLL, gói Debian, gói java, gói OSGi, thậm chí cả tệp tiêu đề C ++ bao gồm tất cả đều có phụ thuộc và gặp phải vấn đề phụ thuộc. Nếu bạn có hai phụ thuộc và mỗi phụ thuộc sử dụng một phiên bản khác nhau của cùng một thứ, thì bạn phải cố gắng giải quyết bằng cách nào đó. Maven không cố gắng giải quyết vấn đề phụ thuộc, mà đưa nó lên hàng đầu và cung cấp các công cụ để giúp quản lý vấn đề, chẳng hạn như bằng cách báo cáo xung đột và cung cấp các phụ thuộc nhất quán cho hệ thống phân cấp của các dự án và trên thực tế, cung cấp quyền kiểm soát tuyệt đối phụ thuộc của một dự án.

Cách tiếp cận thủ công bao gồm các phụ thuộc với mỗi dự án (một người đăng cho biết anh ta kiểm tra tất cả các phụ thuộc vào kiểm soát nguồn) đang dẫn đến nguy cơ sử dụng sai phụ thuộc, chẳng hạn như các cập nhật bị bỏ qua khi một thư viện được cập nhật mà không kiểm tra các bản cập nhật cho các phụ thuộc đó. Đối với một dự án ở bất kỳ quy mô nào, việc quản lý các phần phụ thuộc theo cách thủ công chắc chắn sẽ dẫn đến lỗi. Với maven, bạn có thể cập nhật phiên bản thư viện mà bạn sử dụng và bao gồm các phần phụ thuộc chính xác. Đối với quản lý thay đổi, bạn có thể so sánh tập hợp phụ thuộc cũ (cho toàn bộ dự án của bạn) với tập hợp mới và bất kỳ thay đổi nào có thể được xem xét kỹ lưỡng, kiểm tra, v.v.

Maven không phải là nguyên nhân của vấn đề phụ thuộc, nhưng làm cho nó dễ thấy hơn. Trong việc giải quyết các vấn đề phụ thuộc, maven thực hiện mọi "điều chỉnh" phụ thuộc một cách rõ ràng (thay đổi đối với POM của bạn ghi đè phụ thuộc), thay vì ngầm hiểu, như trường hợp với các lọ được quản lý thủ công trong kiểm soát phiên bản, nơi các lọ chỉ hiện diện, không có gì thời tiết hỗ trợ họ có phụ thuộc chính xác hay không.

Tôi tin rằng Maven có một rep tệ bởi vì hầu hết những người gièm pha đã không quan sát thấy sự kết hợp giữa Maven + Hudson + Sonar . Nếu có, họ sẽ hỏi "làm cách nào để bắt đầu"?

Một số thú cưng của tôi trộm với Maven:

• Định nghĩa XML rất vụng về và dài dòng. Họ chưa bao giờ nghe nói về thuộc tính?

• Trong cấu hình mặc định của nó, nó luôn quét mạng trên mọi hoạt động. Bất kể điều này có hữu ích cho bất cứ điều gì, có vẻ vô cùng ngớ ngẩn khi cần truy cập Internet cho "sạch".

• Một lần nữa trong mặc định, nếu tôi không cẩn thận chỉ định số phiên bản chính xác, nó sẽ kéo các bản cập nhật mới nhất ra khỏi mạng, bất kể các phiên bản mới nhất này có xuất hiện lỗi phụ thuộc hay không. Nói cách khác, bạn đang chịu sự quản lý phụ thuộc của những người khác.

• Giải pháp cho tất cả các truy cập mạng này là tắt nó bằng cách thêm -otùy chọn. Nhưng bạn phải nhớ tắt nó đi nếu bạn thực sự muốn cập nhật phụ thuộc!

• Một giải pháp khác là cài đặt máy chủ "kiểm soát nguồn" của riêng bạn cho các phần phụ thuộc. Ngạc nhiên: Hầu hết các dự án đã có kiểm soát nguồn, chỉ có điều đó hoạt động mà không cần thiết lập bổ sung!

• Các bản dựng của Maven rất chậm. Loay hoay với các bản cập nhật mạng làm giảm bớt điều này, nhưng các bản dựng của Maven vẫn còn chậm. Và dài dòng kinh khủng.

• Plugin Maven (M2Eclipse) tích hợp kém nhất với Eclipse. Eclipse tích hợp hợp lý trơn tru với phần mềm kiểm soát phiên bản và với Ant. Sự tích hợp Maven rất khó so sánh và xấu xí. Tôi đã đề cập đến chậm?

• Maven tiếp tục bị lỗi. Thông báo lỗi không hữu ích. Quá nhiều nhà phát triển đang phải chịu đựng điều này.

Câu hỏi hay. Tôi vừa mới bắt đầu một dự án lớn tại nơi làm việc và một phần của các dự án trước đó là giới thiệu mô-đun cho cơ sở mã của chúng tôi.

Tôi đã nghe những điều tồi tệ về maven. Trên thực tế, đó là tất cả những gì tôi từng nghe về nó. Tôi đã xem xét việc giới thiệu nó để giải quyết cơn ác mộng phụ thuộc mà chúng tôi hiện đang trải qua. Vấn đề mà tôi đã thấy với Maven là nó khá cứng nhắc trong cấu trúc của nó, tức là bạn cần phải tuân theo bố cục dự án của nó để nó hoạt động cho bạn.

Tôi biết hầu hết mọi người sẽ nói gì - bạn không cần phải tuân theo cấu trúc. Quả thực điều đó đúng nhưng bạn sẽ không biết điều này cho đến khi bạn vượt qua đường cong học tập ban đầu, lúc đó bạn đã đầu tư quá nhiều thời gian để đi và vứt bỏ tất cả.

Ant được sử dụng rất nhiều ngày nay, và tôi thích nó. Tính đến điều đó, tôi tình cờ gặp một người quản lý phụ thuộc ít được biết đến tên là Apache Ivy . Ivy tích hợp vào Ant rất tốt và việc thiết lập và hoạt động truy xuất JAR cơ bản rất nhanh chóng và dễ dàng. Một lợi ích khác của Ivy là nó rất mạnh mẽ nhưng khá minh bạch; bạn có thể chuyển các bản dựng bằng các cơ chế như scp hoặc ssh khá dễ dàng; truy xuất phụ thuộc 'chuỗi' qua hệ thống tệp hoặc kho lưu trữ từ xa (khả năng tương thích với kho Maven là một trong những tính năng phổ biến của nó).

Điều đó đã nói lên rằng, cuối cùng thì tôi thấy rất khó chịu khi sử dụng - tài liệu thì rất nhiều, nhưng nó được viết bằng tiếng Anh không tốt có thể gây ra sự thất vọng khi gỡ lỗi hoặc cố gắng tìm ra những gì đã xảy ra.

Tôi sẽ truy cập lại Apache Ivy vào một thời điểm nào đó trong dự án này và tôi hy vọng nó sẽ hoạt động bình thường. Một điều nó đã làm là cho phép chúng tôi như một nhóm tìm ra những thư viện mà chúng tôi phụ thuộc vào và có được một danh sách tài liệu.

Cuối cùng, tôi nghĩ tất cả phụ thuộc vào cách bạn làm việc với tư cách cá nhân / nhóm và những gì bạn cần để giải quyết các vấn đề phụ thuộc của mình.

Bạn có thể thấy các tài nguyên sau liên quan đến Ivy hữu ích:

• So sánh Apache Ivy vs Maven 2
• Câu hỏi thường gặp về Apache Ivy
• Danh sách tính năng của Apache Ivy

Tôi yêu Maven - nó giúp tăng năng suất và tôi rất vui vì tôi không còn sử dụng Ant nữa (phew!)

Nhưng nếu tôi có thể thay đổi mọi thứ, nó sẽ là:

1. Làm cho pom.xmltệp bớt dài dòng
2. Giúp dễ dàng bao gồm .jars không phải từ kho lưu trữ.

Có rất nhiều lý do khiến mọi người không thích Maven, nhưng hãy đối mặt với nó, họ rất chủ quan . Maven ngày nay với một số cuốn sách hay (và miễn phí), tài liệu tốt hơn, bộ plugin lớn hơn và nhiều bản xây dựng dự án thành công mang tính tham khảo không giống với Maven như một hoặc hai năm trước.

Sử dụng Maven trong các dự án đơn giản là rất dễ dàng, với những dự án lớn hơn / phức tạp thì cần phải có thêm kiến ​​thức và hiểu sâu hơn về triết lý của Maven - có thể ở cấp công ty, một vị trí dành cho Maven guru như quản trị mạng. Nguồn chính của Maven ghét các trạng thái thường là sự thiếu hiểu biết .

Một vấn đề khác đối với Maven là thiếu tính linh hoạt như trong Ant. Nhưng hãy nhớ Maven đã thiết lập các quy ước - việc tuân thủ chúng có vẻ khó khăn ngay từ đầu, nhưng cuối cùng thường cứu vãn khỏi các vấn đề.

Thành công hiện tại của Maven chứng tỏ giá trị của nó. Tất nhiên không ai là hoàn hảo và Maven có một số khuyết điểm và những điều kỳ quặc của nó nhưng theo ý kiến ​​của tôi thì Maven từ từ đánh gục đối thủ của mình.

Tôi sẽ không nói rằng nó có một đại diện tồi tệ vì nó có một đại diện hỗn hợp. Nếu dự án của bạn tuân theo mô hình "quy ước về cấu hình" do Maven ủng hộ thì bạn có thể nhận được rất nhiều đòn bẩy từ nó. Nếu dự án của bạn không phù hợp với thế giới quan của Maven thì nó có thể trở thành một gánh nặng.

Để đạt được điều đó, nếu bạn có quyền kiểm soát dự án, thì Maven có thể là con đường để đi. Nhưng nếu bạn không làm như vậy và bố cục được xác định bởi một người không phải là fan hâm mộ của Maven, nó có thể rắc rối hơn đáng giá. Các dự án Maven hạnh phúc nhất có lẽ là những dự án bắt đầu như các dự án Maven.

Đối với tôi, có nhiều ưu điểm cũng như nhược điểm khi sử dụng maven vs ant cho các dự án nội bộ. Tuy nhiên, đối với các dự án mã nguồn mở, tôi nghĩ Maven đã có tác động lớn trong việc giúp nhiều dự án xây dựng dễ dàng hơn nhiều. Cách đây không lâu, phải mất hàng giờ để biên dịch dự án OSS Java (dựa trên kiến) trung bình, phải đặt hàng đống biến, tải xuống các dự án phụ thuộc, v.v.

Bạn có thể làm bất cứ điều gì với Maven mà bạn có thể làm với Ant, nhưng Ant không khuyến khích bất kỳ tiêu chuẩn nào, Maven thực sự khuyên bạn nên tuân theo cấu trúc của nó, nếu không sẽ hiệu quả hơn. Đúng vậy, một số điều khó khăn khi thiết lập với Maven có thể dễ dàng thực hiện với Ant, nhưng kết quả cuối cùng hầu như luôn luôn là thứ dễ xây dựng hơn từ quan điểm của những người chỉ muốn kiểm tra một dự án và đi.

Nếu bạn định đặt cược doanh nghiệp hoặc công việc của mình vào một dự án phát triển, bạn muốn kiểm soát các nền tảng - tức là hệ thống xây dựng. Với Maven, bạn không kiểm soát được. Nó mang tính khai báo và không rõ ràng. Các nhà phát triển maven-framework không có ý tưởng làm thế nào để xây dựng một hệ thống minh bạch hoặc trực quan và điều này rõ ràng từ đầu ra nhật ký và tài liệu.

Quản lý sự phụ thuộc rất hấp dẫn vì nó có thể giống bạn một lúc nào đó khi bắt đầu dự án nhưng được cảnh báo, về cơ bản nó đã bị phá vỡ và cuối cùng sẽ khiến bạn rất đau đầu. Khi hai phụ thuộc có các phụ thuộc thoáng qua không tương thích, bạn sẽ bị chặn bởi một tổ chuột phức tạp sẽ phá vỡ quá trình xây dựng cho toàn bộ nhóm của bạn và chặn phát triển trong nhiều ngày. Quá trình xây dựng với Maven cũng nổi tiếng là không nhất quán đối với các nhà phát triển khác nhau trong nhóm của bạn do các trạng thái không nhất quán của kho lưu trữ cục bộ của họ. Tùy thuộc vào thời điểm nhà phát triển tạo môi trường của họ hoặc những dự án khác mà họ đang thực hiện, họ sẽ có kết quả khác nhau. Bạn sẽ thấy rằng bạn đang xóa toàn bộ kho lưu trữ cục bộ của mình và yêu cầu Maven tải lại các lọ thường xuyên hơn nhiều so với lần đầu tiên thiết lập cho một chi nhánh nhà phát triển. Tôi tin rằng OSGI là một sáng kiến ​​đang cố gắng khắc phục sự cố cơ bản này. Tôi sẽ nói rằng có lẽ nếu một cái gì đó cần phải phức tạp như vậy, thì tiền đề cơ bản là sai.

Tôi đã là người dùng / nạn nhân của maven hơn 5 năm nay và tôi phải nói rằng điều đó sẽ giúp bạn tiết kiệm thời gian hơn rất nhiều khi chỉ kiểm tra các phụ thuộc vào kho lưu trữ nguồn của bạn và viết các tác vụ kiến ​​đơn giản và đẹp mắt. Với ant, bạn biết chính xác những gì hệ thống xây dựng của bạn đang làm.

Tôi đã trải qua rất nhiều, nhiều tuần mất thời gian ở một số công ty khác nhau do các vấn đề của Maven.

Gần đây, tôi đã cố gắng làm cho một dự án GWT / Maven / Eclipse cũ trở lại hoạt động và 2 tuần sau tất cả thời gian rảnh rỗi của tôi, tôi vẫn không thể xây dựng nó một cách nhất quán. Tôi nghĩ đã đến lúc cắt lỗ và phát triển bằng cách sử dụng ant / eclipse ...

Câu trả lời ngắn gọn: Tôi thấy rất khó để duy trì một hệ thống xây dựng Maven và tôi muốn chuyển sang Gradle ngay khi có thể.

Tôi đã làm việc với Maven hơn bốn năm. Tôi tự gọi mình là một chuyên gia về xây dựng hệ thống bởi vì trong (ít nhất) năm công ty gần đây nhất mà tôi đã tham gia, tôi đã thực hiện cải tạo lớn về cơ sở hạ tầng xây dựng / triển khai.

Một số bài học tôi đã học được:

• Hầu hết các nhà phát triển có xu hướng không dành nhiều thời gian suy nghĩ về việc xây dựng hệ thống; kết quả là, bản dựng biến thành một mớ hỗn độn mì Ý với những vụ hack, nhưng họ đánh giá cao nó khi mớ hỗn độn đó được dọn dẹp và hợp lý hóa.
• Để đối phó với sự phức tạp, tôi thà có một hệ thống minh bạch bộc lộ sự phức tạp (như Ant) hơn là một hệ thống cố gắng biến những thứ phức tạp trở nên đơn giản bằng cách áp đặt những hạn chế cứng nhắc, như Maven. Hãy nghĩ về Linux và Windows.
• Maven có rất nhiều lỗ hổng trong chức năng đòi hỏi các giải pháp thay thế bằng byzantine. Điều này dẫn đến các tệp POM không thể hiểu được và không thể hiểu được.
• Ant siêu linh hoạt và dễ hiểu, nhưng các tệp Ant cũng có thể trở nên khá lớn, vì nó quá thấp.
• Đối với bất kỳ dự án quan trọng nào, các nhà phát triển phải tạo cấu trúc xây dựng / triển khai của riêng họ ngoài những gì công cụ cung cấp; sự phù hợp của cấu trúc với dự án liên quan nhiều đến việc nó có dễ bảo trì hay không. Các công cụ tốt nhất sẽ hỗ trợ bạn trong việc tạo ra một cấu trúc và không chống lại bạn.

Tôi đã xem xét Gradle một chút và có vẻ như nó có tiềm năng trở thành tốt nhất của cả hai thế giới, cho phép kết hợp giữa mô tả xây dựng khai báo và thủ tục.

Nó phức tạp hơn ngôn ngữ bạn sử dụng để viết dự án của mình. Làm cho nó đúng cấu hình khó hơn lập trình thực tế.

Tôi đã đấu tranh theo cách của mình để vượt qua hầu hết / tất cả những tiêu cực được đề cập ở đây, và những phản đối tương tự từ các đồng đội, và đồng ý với tất cả. Nhưng tôi đã cố gắng hết sức và sẽ tiếp tục làm như vậy bằng cách giữ vững mục tiêu duy nhất mà chỉ maven (hoặc có lẽ là gradle) mới thực sự thực hiện được.

Nếu bạn đang tối ưu hóa cho các đồng nghiệp ( nhà phát triển mã nguồn mở ), ant / make / any sẽ làm được. Nếu bạn đang cung cấp chức năng cho những người không phải ngang hàng ( người dùng ), chỉ maven / gradle / etc mới làm được.

Chỉ maven mới cho phép bạn phát hành một gói nhỏ mã nguồn + poms (không nhúng các lọ phụ thuộc lib / nhị phân có tên khó hiểu và không có thông tin phụ thuộc) với bố cục dự án tiêu chuẩn được ghi chép đầy đủ có thể được tải bởi bất kỳ IDE nào bởi một người chưa hiểu các quy ước về bố cục theo phong cách riêng của nhà phát triển. Và có một thủ tục cài đặt một nút (mvn install) xây dựng mọi thứ trong khi có được bất kỳ phụ thuộc nào bị thiếu.

Kết quả là một đoạn đường nối dễ dàng mà người dùng có thể theo dõi để tìm đường vào mã, nơi các poms có thể chỉ họ đến tài liệu liên quan.

Ngoài yêu cầu (không thể thiếu) đó, tôi không thích maven nhiều như bất kỳ ai.