2009-03-06 9 views
10

मैं एक विरासत जावा कोडेबेस के साथ फंस गया हूं जिसमें संकलन के हजारों हैं जब आप इसे संकलित करते हैं। मुझे वास्तव में इन सभी चेतावनियों के स्रोत को ठीक करना अच्छा लगेगा, लेकिन दुर्भाग्य से यह मेरी कंपनी में इस समय कोई विकल्प नहीं है (अन्य चीजें जैसे "राजस्व उत्पन्न करने वाले नए उत्पाद" को चार्ज करने वाले लोगों द्वारा उच्च प्राथमिकता माना जाता है; कल्पना है कि) ।जावाडोक संकलन के दौरान मैं चेतावनी (कोडबेस-चौड़ा) कैसे दबा सकता हूं?

अब, मैं इन सभी चेतावनियों के साथ बस रह सकता हूं, अगर यह इस तथ्य के लिए नहीं था कि वे हमारे निरंतर निर्माण सर्वर से आउटपुट में वास्तविक त्रुटियों को ढूंढना मुश्किल बनाते हैं। बिल्ड सर्वर सिर्फ एक चींटी कॉल का उपयोग करता है, कुछ भी फैंसी नहीं है, लेकिन अब तक मैं चेतावनी आउटपुट को रोकने के लिए इस कॉल को कैसे संशोधित कर सकता हूं इसके लिए कहीं भी कुछ भी नहीं ढूंढ पाया।

कोड के माध्यम से जाकर और @SuppressWarnings एनोटेशन जोड़ना हर जगह काम करेगा, लेकिन यह सभी चेतावनियों के स्रोतों को ठीक करने और ठीक करने के रूप में लगभग दर्द का भी होगा।

<javadoc suppressWarrnings="true" 

या कुछ इसी तरह, उत्पादन नहीं जावाडोक संकलक सब चेतावनी संदेश बनाने के लिए: तो क्या मैं वास्तव में खुशी होगी अगर कोई बस किसी तरह से मैं कर सकता था। क्या ऐसा कुछ भी है (वैश्विक जावाडोक चेतावनी अक्षम) संभव है?

उत्तर

5

चींटी कार्य और जावाडोक टूल दोनों में वैश्विक स्तर पर चेतावनियों को अक्षम करने का कोई तरीका नहीं है।

एक संभावित कामकाज मैं सोच सकता हूं कि जावडोक कार्य को शेष निर्माण से अलग एंटी कॉल के रूप में चलाने के लिए है। आप कंसोल की बजाय आउटपुट को लॉग फ़ाइल में रीडायरेक्ट करने के लिए एंटी पर -logfile तर्क का उपयोग कर सकते हैं।

6

-क्वेट ध्वज आज़माएं।

+0

बेवकूफ सवाल: क्या आपको पता है कि इस ध्वज को कैसे पास किया जाए चींटी? – machineghost

+0

मैं additionalparam – anon

+0

साथ लगता है कि यह है कि यह प्रयास करें: <जावाडोक // अन्य तत्वों additionalparam = "-quiet" /> – anon

1

मार्क का जवाब मेरे लिए अच्छा लगता है, और शायद क्रूज़ कंट्रोल निरंतर बिल्ड सिस्टम का उपयोग न करने वाले किसी के लिए भी अच्छा काम करेगा। हालांकि, मैंने पाया कि किसी भी व्यक्ति के लिए (मेरे जैसे) उस प्रणाली का उपयोग कर रहा है, एक और तरीका है।

क्रूज़ नियंत्रण कई एक्सएसएलटी स्टाइलशीट का उपयोग कर अपनी रिपोर्ट को इकट्ठा करता है। हमारे मामले में इन स्टाइलशीट में रहते थे:

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

लेकिन जब से मैं अपने स्थापना सेटअप नहीं किया है, मुझे लगता है कि अगर एक मानक मार्ग है या नहीं पता नहीं है। भले ही, आप अपनी स्थापना में एक समतुल्य निर्देशिका खोजने में सक्षम होना चाहिए। उस निर्देशिका के अंदर error.xsl नामक एक फ़ाइल है। चेतावनियों से छुटकारा पाने के लिए आपको उस फ़ाइल में दो बदलाव करने की आवश्यकता होगी, जिनमें से दोनों मौजूदा नियमों पर टिप्पणी करने में शामिल हैं।

बदलें:

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

साथ:

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

यह कर देगा "त्रुटि गिनती" त्रुटियों + चेतावनी की गिनती वास्तविक त्रुटियों की गिनती के बजाय हो।

फिर, बदल देते हैं:

<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> 

साथ:

<!--<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>--> 

यह वास्तविक चेतावनी खुद को छुपा देगा।वैकल्पिक रूप से आप हमेशा टिप्पणी कोड को हटा सकते हैं, लेकिन फिर भी यदि आप कभी भी अपनी चेतावनियां वापस लेना चाहते हैं तो आपको वास्तव में फ़ाइल का बैक अप लेना चाहिए। इसके अलावा, एक्सएसएलटी किसी भी गैर-एक्सएसएलटी मार्कअप को अनदेखा करता है, ताकि आप चेतावनियों के साथ अन्य चीजों को पूरी तरह खत्म कर सकें: उदाहरण के लिए, आप सभी चेतावनियों को एक डीआईवी में लपेट सकते हैं, और फिर चेतावनियों को "पतन" करने के लिए सीएसएस/जावास्क्रिप्ट का उपयोग कर सकते हैं पूरी तरह से उन्हें हटाने के बजाय।

हालांकि मुझे अंततः इस समाधान को खोजना पड़ा, हालांकि सभी उत्तरों ने मुझे यह समझने में मदद की कि क्या हो रहा था, इसलिए मदद के लिए सभी को धन्यवाद।

0

मैंने अभी पाया कि मेरे पिछले उत्तर में मैंने जो वर्णन किया है उसका थोड़ा बेहतर संस्करण था। Error.xsl को संपादित करने के बजाय, buildresults.xsl संपादित करें। इस फ़ाइल में एक टिप्पणी में शामिल हैं:

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

आपको लगता है कि टिप्पणी की सलाह (दो पंक्तियों में यह उल्लेख है बाहर टिप्पणी और एक लाइन यह उल्लेख है uncomment) आप एक ही सटीक प्रभाव मिलता है, लेकिन साथ संकलन त्रुटियों शामिल का पालन करें।

इस विधि के साथ मेरे पिछले एक से परेशान क्यों? खैर मुझे लगता है (मुझे वास्तव में यह बेहतर परीक्षण करना चाहिए था, लेकिन मुझे आलसी हो गई) कि मेरी पिछली विधि संकलन त्रुटियों को खाती है; यह विधि उन्हें संरक्षित करती है।

8

जावा 8 में आप javadoc कार्य में जोड़ सकते हैं। (Source)

+0

मैं अभी भी चेतावनी देता हूं जब मैं ऐसा करता हूं, लेकिन यह 99 चेतावनियों को देखने से बेहतर तरीका है कि मुझे (भी) को ठीक करने का कोई समय नहीं है। –

1

आजकल कुछ जावाडॉक गैर मानक विकल्प आपको अत्यधिक संख्या में त्रुटियों और/या चेतावनियों से बचने की अनुमति देते हैं। जावाडोक की मदद की जांच करें (javadoc -X निष्पादित करें); निम्नलिखित गैरमानक विकल्प उपलब्ध होना चाहिए:

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

-Xmaxerrs त्रुटियों की अधिकतम संख्या सेट मुद्रित करने के लिए -Xmaxwarns चेतावनी की अधिकतम संख्या सेट मुद्रित करने के लिए सक्षम बनाता है -Xdoclint या जावाडोक टिप्पणियों में समस्याओं के लिए विशिष्ट चेकों अक्षम करता है।

उदाहरण के लिए, -Xdoclint:none निर्दिष्ट करना javadoc टिप्पणियों में से अधिकांश समस्याओं के लिए विशिष्ट जांच अक्षम कर देगा; और -Xmaxwarns 1 चेतावनियों की संख्या को 1 तक सीमित कर देगा (मैंने -Xmaxwarns 0 को आजमाया, लेकिन फिर यह सभी चेतावनियों को मुद्रित करता है, इसलिए मेरा अनुमान है कि 0 का मतलब कोई सीमा नहीं है)

संबंधित मुद्दे

 संबंधित मुद्दे