2009-03-06 28 views
10

Tôi bị kẹt với một codebase Java kế thừa có nhiều cảnh báo khi bạn biên dịch nó. Tôi rất muốn thực sự khắc phục nguồn gốc của tất cả các cảnh báo này, nhưng tiếc là không phải là một lựa chọn tại thời điểm này tại công ty của tôi (những thứ khác như "tạo ra sản phẩm mới tạo doanh thu" được coi là ưu tiên cao hơn bởi những người phụ trách; .Làm cách nào để ngăn chặn cảnh báo (toàn bộ mã) trong quá trình biên dịch javadoc?

Bây giờ, tôi chỉ có thể sống với tất cả các cảnh báo này, nếu không thực tế là họ sẽ gặp khó khăn khi tìm lỗi thực tế trong đầu ra từ máy chủ tạo liên tục của chúng tôi. Máy chủ xây dựng chỉ sử dụng một cuộc gọi kiến, không có gì lạ mắt, nhưng cho đến nay tôi đã không thể tìm thấy bất cứ điều gì bất cứ nơi nào để làm thế nào tôi có thể sửa đổi cuộc gọi này để ngăn chặn đầu ra cảnh báo.

Đi qua mã và thêm chú thích @SuppressWarnings ở mọi nơi sẽ hoạt động, nhưng nó cũng sẽ gần như là một nỗi đau khi trải qua và sửa tất cả các nguồn cảnh báo. Vì vậy, những gì tôi thực sự rất muốn là nếu có chỉ là một số cách tôi có thể làm:

<javadoc suppressWarrnings="true" 

hoặc một cái gì đó tương tự, để làm cho trình biên dịch javadoc không đầu ra tất cả các thông điệp cảnh báo. Là bất cứ điều gì như thế này (toàn cầu javadoc cảnh báo vô hiệu hóa) có thể?

Trả lời

5

Cả tác vụ kiến ​​và công cụ javadoc đều không có cách nào để tắt cảnh báo trên toàn cầu.

Một giải pháp có thể xảy ra mà tôi có thể nghĩ là chạy tác vụ javadoc dưới dạng cuộc gọi kiến ​​riêng biệt với phần còn lại của bản dựng. Bạn có thể sử dụng đối số -logfile để ant để chuyển hướng đầu ra tới tệp nhật ký thay vì bảng điều khiển.

6

Thử cờ -quiet.

+0

Câu hỏi ngu ngốc: bạn có biết cách vượt qua lá cờ này không kiến? – machineghost

+0

Tôi nghĩ rằng với additionalparam – anon

+0

Hãy thử nó như thế này: anon

1

Câu trả lời của Mark có vẻ phù hợp với tôi, và có lẽ sẽ hoạt động tốt cho bất kỳ ai không sử dụng hệ thống xây dựng liên tục của Cruise Control. Tuy nhiên, tôi phát hiện ra rằng đối với bất kỳ ai (như tôi) đang sử dụng hệ thống đó, có một cách khác.

Kiểm soát hành trình tập hợp các báo cáo của nó bằng cách sử dụng một số biểu định kiểu XSLT. Trong trường hợp của chúng tôi, các bảng định kiểu này được lưu trú tại:

~/applications/cruisecontrol-bin-2.7.3/webapps/cruisecontrol/xsl 

nhưng vì tôi không thiết lập cài đặt, tôi không biết đó có phải là đường dẫn chuẩn hay không. Bất kể, bạn sẽ có thể tìm thấy một thư mục tương đương trong cài đặt của bạn. Bên trong thư mục đó là một tệp có tên là error.xsl. Để loại bỏ các cảnh báo, bạn sẽ cần thực hiện hai thay đổi đối với tệp đó, cả hai đều liên quan đến việc nhận xét các quy tắc hiện có.

Thay thế:

<xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/> 

với:

<!--  <xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/>--> 
<xsl:variable name="total.errorMessage.count" select="count($error.messages)"/> 

Điều này sẽ làm cho "đếm lỗi" là một số các lỗi thực tế, chứ không phải là một số các lỗi + cảnh báo.

Sau đó, thay thế:

<xsl:template match="message[@priority='warn']" mode="errors"> 
    <xsl:if test="not(starts-with(text(),'cvs update'))"> 
     <xsl:value-of select="text()"/><br class="none"/> 
    </xsl:if> 
</xsl:template> 

với:

<!--<xsl:template match="message[@priority='warn']" mode="errors"> 
    <xsl:if test="not(starts-with(text(),'cvs update'))"> 
     <xsl:value-of select="text()"/><br class="none"/> 
    </xsl:if> 
</xsl:template>--> 

này sẽ ẩn những lời cảnh báo thực tế bản thân.Ngoài ra, bạn luôn có thể xóa mã đã nhận xét, nhưng sau đó bạn nên thực sự sao lưu tệp trước, trong trường hợp bạn muốn nhận lại cảnh báo. Ngoài ra, XSLT bỏ qua bất kỳ đánh dấu XSLT nào, vì vậy bạn có thể thực hiện những điều khác với cảnh báo ngoài việc loại bỏ chúng hoàn toàn: ví dụ, bạn có thể bọc tất cả các cảnh báo trong DIV và sau đó sử dụng CSS/Javascript để "thu gọn" các cảnh báo thay vì xóa chúng hoàn toàn.

Mặc dù cuối cùng tôi đã tự mình khám phá giải pháp này, tất cả các câu trả lời ở đây đã giúp tôi hiểu những gì đang diễn ra, vì vậy cảm ơn tất cả vì sự giúp đỡ.

0

Tôi vừa phát hiện ra có một biến thể hơi tốt hơn về những gì tôi đã mô tả trong câu trả lời trước đây của mình. Thay vì chỉnh sửa errors.xsl, hãy chỉnh sửa buildresults.xsl. Tập tin này có chứa một bình luận:

for traditional cc display of only compile errors and warnings 
comment out mode="errors" and uncomment mode="compile" and mode="javadoc" 

Nếu bạn làm theo lời khuyên của bình luận đó (nhận xét ra hai dòng nó đề cập đến và bỏ một dòng nó đề cập đến), bạn có được hiệu quả chính xác như nhau, nhưng với lỗi biên dịch bao gồm.

Tại sao phải quan tâm đến phương pháp này so với phương pháp trước đây của tôi? Tôi nghĩ rằng (Tôi thực sự nên đã thử nghiệm này tốt hơn, nhưng tôi đã lười biếng) rằng phương pháp trước đây của tôi ăn lỗi biên dịch; phương pháp này bảo tồn chúng.

8

Trong Java 8, bạn có thể thêm additionalparam="-Xdoclint:none" vào tác vụ javadoc. (Source)

+0

Tôi vẫn thấy cảnh báo khi tôi làm điều này, nhưng nó là cách tốt hơn so với nhìn thấy 99 cảnh báo rằng tôi (cũng) không có thời gian để sửa chữa. –

1

Ngày nay, một số tùy chọn không chuẩn Javadoc cho phép bạn tránh quá nhiều lỗi và/hoặc cảnh báo. Kiểm tra sự giúp đỡ của javadoc (thực thi javadoc -X); các tùy chọn chuẩn sau đây nên có sẵn:

-Xmaxerrs <number> 
-Xmaxwarns <number>    
-Xdoclint:(all|none|[-]<group>) 

-Xmaxerrs đặt số lượng tối đa các lỗi in -Xmaxwarns đặt số lượng tối đa cảnh báo để in -Xdoclint cho phép hoặc vô hiệu hóa kiểm tra cụ thể cho các vấn đề trong ý kiến ​​javadoc.

Ví dụ: chỉ định -Xdoclint:none sẽ tắt kiểm tra cụ thể cho hầu hết các sự cố trong nhận xét javadoc; và -Xmaxwarns 1 sẽ giới hạn số cảnh báo thành 1 (tôi đã thử -Xmaxwarns 0, nhưng sau đó nó in tất cả cảnh báo, vì vậy tôi đoán là 0 có nghĩa là không giới hạn)

Các vấn đề liên quan