2013-02-12 7 views
7

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

है, उन सभी का केवल अच्छी बात है कि वर्ग है जो मुझे बदलने के लिए ठीक से decompiled किया जा सकता है की जरूरत है, तो निम्न के लिए चला गया:

  • मैं पूरी जार फ़ाइल decompiled और कुछ वर्गों के साथ समाप्त हो गया ( जीबीएक्स वाले) खाली या गलत तरीके से कार्यान्वित तरीकों के साथ।
  • मैंने स्टब ऑब्जेक्ट्स के गलत तरीकों के शरीर पर टिप्पणी की, सही कक्षाओं में आवश्यक परिवर्तनों को लागू किया और पुनः संकलित किया।
  • मैंने पुरानी जार फ़ाइल ली, इसे खोल दिया और मैन्युअल रूप से पुरानी कक्षा को नए के साथ बदल दिया।

और जिसके परिणामस्वरूप जार काम अपेक्षा के अनुरूप।

अब मेरी सवाल यह है: मुझे लगता है कि Maven का उपयोग कर के सभी कर सकता हूँ?

विचार संसाधनों के रूप में JiBX वर्ग फ़ाइलों डाल करने के लिए, और स्रोत फ़ाइलों के रूप में ठूंठ समकक्ष रखना और फिर Maven जाने होगा:

  • हमेशा की तरह सब कुछ संकलित करें, लक्ष्य में सभी संकलित वर्ग फ़ाइलों डाल फ़ोल्डर
  • लक्ष्य फ़ोल्डर से स्टब क्लास फ़ाइलों को निकालें और पुरानी प्रीकंपील्ड क्लास फाइलों के साथ उन्हें बदलें
  • जार पैकेज करें।

किस तरीके से की सलाह देंगे?

अद्यतन

मैं निर्भरता परियोजना संरचना के बारे में कुछ और जानकारी दे:

सभी वर्गों को एक ही पैकेज के अंदर कर रहे हैं:

my.project.domain.JiBX__c_GeneratedObfuscatedClass1.java 
my.project.domain.JiBX__c_GeneratedObfuscatedClass2.java 
my.project.domain.JiBX__c_GeneratedObfuscatedClass3.java 
my.project.domain.CustomizableClass1.java 
my.project.domain.CustomizableClass2.java 
my.project.domain.CustomizableClass3.java 

JiBX कक्षाएं निर्भरता के रूप में ठीक से आयात नहीं किया जाता और अगर मैं प्रोजेक्ट स्रोत में किसी भी कस्टमिज़ेबल क्लासेस को डालने का प्रयास करता हूं और जीबीएक्स को निर्भरता में रखने देता हूं, तो संकलक गायब तरीकों की रिपोर्ट करता है।

मैंने सुझाए गए छाया प्लगइन का उपयोग करने का भी प्रयास किया, लेकिन चूंकि मुझे अपने स्रोत पथ में जीबीएक्स कक्षाओं को शामिल करने की आवश्यकता है, इसलिए मैं जार निर्भरता से संकुल जीबीएक्स कक्षाओं में शामिल होना और अनुकूलित कस्टमाइज़ेबल क्लासेस को संकलित करना होगा, लेकिन कस्टमाइज़ेबल क्लासेस को छोड़ना जार डेप और संकलित जीबीएक्स कक्षाएं।

मैं जैसे कि यह काम कर सकते हैं लगता है, लेकिन मैं मानता हूं कि मैं अभी भी यह कर के रास्ते भी नहीं मिला। किसी भी सुराग का बहुत स्वागत किया जाएगा।

मैं अंत में एक प्रोजेक्ट बनाया:

अद्यतन 2 (संकल्प)

मैं यहाँ यह बताएं कि मैं अंत में यह कामयाब छाया प्लगइन का उपयोग कर के रूप में सुझाव दिया है, बस किसी और मामले में किसी को भी ऐसा ही करने की जरूरत है एक ही पैकेज के अंदर विघटित कक्षाओं के साथ, और उन विधियों को छोड़ दिया जो अपूर्ण नहीं होना चाहते थे।

<build> 
<plugins> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-shade-plugin</artifactId> 
     <version>2.0</version> 
     <executions> 
      <execution> 
       <phase>package</phase> 
       <goals> 
        <goal>shade</goal> 
       </goals> 
       <configuration> 
        <artifactSet> 
         <includes> 
          <include>${project.groupId}:${project.artifactId}</include> 
          <include>TheDamnedProject:WithoutSources</include> 
         </includes> 
        </artifactSet> 
        <filters> 
         <filter> 
          <artifact>TheDamnedProject:WithoutSources</artifact> 
          <includes> 
           <!-- These classes will be taken directly from dependency JAR --> 
           <include>my/package/ClassWhichCouldNotBeDecompiled1.class</include> 
           <include>my/package/ClassWhichCouldNotBeDecompiled2.class</include> 
           <include>my/package/ClassWhichCouldNotBeDecompiled3.class</include> 
           <include>my/package/ClassWhichCouldNotBeDecompiled4.class</include> 
          </includes> 
         </filter> 
         <filter> 
          <artifact>${project.groupId}:${project.artifactId}</artifact> 
          <excludes> 
           <!-- These classes will be overridden by the ones inside the JAR --> 
           <exclude>my/package/ClassWhichCouldNotBeDecompiled1.class</exclude> 
           <exclude>my/package/ClassWhichCouldNotBeDecompiled2.class</exclude> 
           <exclude>my/package/ClassWhichCouldNotBeDecompiled3.class</exclude> 
           <exclude>my/package/ClassWhichCouldNotBeDecompiled4.class</exclude> 
          </excludes> 
         </filter> 
        </filters> 
       </configuration> 
      </execution> 
     </executions> 
    </plugin> 
</plugins> 

धन्यवाद:

pom.xml में मैं निम्नलिखित जोड़ा गया!

कार्ल्स

+1

क्या आपको गतिशील रूप से होने की आवश्यकता है?क्या आपके बदले गए जेएआर को तैनात करने और इसे निर्भरता के रूप में संदर्भित करने का नकारात्मक पक्ष होगा? –

+1

मैं इसे मैन्युअल रूप से कर सकता हूं, लेकिन दूसरी बार मुझे इसे थोड़े समय में संशोधित करने की आवश्यकता है और मैं गारंटी नहीं दे सकता कि अगला डेवलपर समझता है कि क्या हो रहा है, इसलिए मैं इसे जितना संभव हो सके स्वचालित बनाना चाहता हूं –

+0

यह भी देखें http://stackoverflow.com/q/1832853/545127 – Raedwald

उत्तर

6

यहाँ मैं यह कैसे कर देगा:

  • इस जार फ़ाइल के लिए एक नया Maven परियोजना, पैकेजिंग प्रकार जार के साथ
  • निर्भरता
  • के रूप में मूल जार फ़ाइल शामिल बनाएं
  • src फ़ोल्डर में एक decompiled .java फ़ाइल जोड़ें

यह आपको उस बिंदु पर ले जाना चाहिए जहां .java फ़ाइल संकलित की जा सकती है, क्योंकि जार फ़ाइल के अन्य वर्ग उपलब्ध हैं।

अब आपके पास दो जार फ़ाइलें हैं: एक मूल, और एक जिसमें केवल एक पुन: संकलित और परिवर्तित वर्ग होना चाहिए।

आपके एप्लिकेशन क्लास पथ में दोनों जोड़ना काम कर सकता है, लेकिन क्लासपाथ पर ऑर्डर पर निर्भर करेगा।

आप एक जार फ़ाइल के साथ खत्म करना चाहते हैं, मैं Maven शेड प्लगइन (http://maven.apache.org/plugins/maven-shade-plugin/) है, जो आपको कई स्रोतों से सामग्री के साथ एक नया जार फ़ाइल बनाने के लिए अनुमति देगा पर एक नज़र लेने के लिए सलाह देते हैं। यह आपको नई जार फ़ाइल में जो फ़िल्टर करता है उसे फ़िल्टर करने की अनुमति देगा।

मेवेन छाया प्लगइन आपको यह निर्दिष्ट करने की अनुमति देता है कि प्रत्येक आर्टिफैक्ट से कौन से वर्ग शामिल हैं। यह वाइल्डकार्ड का उपयोग करता है और इसके लिए टैग को शामिल/बहिष्कृत करता है, जैसा कि यहां बताया गया है: http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html

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

नई जार फ़ाइल के संस्करण संख्या के लिए, मैं मूल की विविधता का उपयोग करने की अनुशंसा करता हूं। उसी groupId और artifactId का उपयोग करें, फिर संस्करण संख्या संशोधित करें। यदि मूल में 1.0.2 है, तो आपकी नई, पैच की गई फ़ाइल को 1.0.2-1 के रूप में रिलीज़ किया जाना चाहिए, यह इंगित करने के लिए कि यह 1.0.2 स्रोतों पर आधारित है। यदि आपको अतिरिक्त परिवर्तन करने की आवश्यकता है, तो इसे 1.0.2-2 और इसी तरह जारी करें। इससे यह समझना आसान हो जाएगा कि आपके पैच किस संस्करण पर आधारित हैं, और बढ़ते पैच नंबर आपको रिलीज को डिस्टिंग करने का साधन देंगे।

+0

वाह, यह एक तेज प्रतिक्रिया थी! एक विकल्प की तरह लगता है, लेकिन मैंने कुछ ऐसा करने की कोशिश की: केवल जीबीएक्स कक्षाओं वाले एक पतले जार का निर्माण किया और इसे संशोधित करने के लिए कक्षाओं वाले प्रोजेक्ट की निर्भरता के रूप में सेट किया। किसी भी तरह से इसे जीबीएक्स कक्षाओं में कुछ तरीकों से नहीं मिला ... –

+0

क्या आप सुनिश्चित हैं कि सभी निर्भरता आपके द्वारा बनाई गई जार फ़ाइल में हैं? छाया प्लगइन आपको उन कक्षाओं को निर्दिष्ट करने की अनुमति देगा जिन्हें आप मूल जार से पुन: उपयोग करना चाहते हैं, और फिर अपना स्वयं का जोड़ें। मैं मूल के एक संशोधित संस्करण संख्या का उपयोग कर परिणामी जार को जारी करने की सलाह देता हूं (उत्तर देखें, मैंने कुछ विवरण जोड़े हैं)। – nwinkler

+0

nwinkler दृष्टिकोण काम करना चाहिए। शायद आपकी प्रक्रिया में कुछ गलत हो गया। शायद संस्करण या पतली जार की सामग्री के बारे में कुछ भ्रम .. –

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