2012-01-26 17 views
11

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

समस्या कुछ एनोटेशन के साथ विशेष इंटरफ़ेस कार्यान्वयन/कक्षाओं के लिए स्कैनिंग क्लासपाथ के साथ है। मैं निम्नलिखित तरीके से कक्षाएं स्कैन करने के लिए Reflections पुस्तकालय का उपयोग कर रहा:

private Set<Class< ? extends MyInterface >> scan(final String packageName) { 
    final Reflections reflections = new Reflections(packageName); 
    return reflections.getSubTypesOf(MyInterface.class); 
} 

दुर्भाग्य से, इस विधि खाली सेट देता है।

/home/pd5108/apache-maven-2.2.1/boot/classworlds-: जब मैं कक्षा का विस्तार org.apache.maven.plugin.AbstractMojo (समान के भीतर जो मैं Reflections उपयोग कर रहा हूँ) मैं निम्नलिखित परिणाम प्राप्त में मेरी classpath प्रिंट 1.1.jar

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

यहाँ जिस तरह से कैसे classpath बाहर मुद्रित किया जाता है:

URL[] urls = ((URLClassLoader)sysClassLoader).getURLs(); 

for(int i=0; i< urls.length; i++) { 
    System.out.println(urls[i].getFile()); 
} 

उत्तर

5

आवश्यक मोजो वर्ग क्षेत्रों:

/** 
    * The project currently being built. 
    * 
    * @parameter expression="${project}" 
    * @readonly 
    * @required 
    */ 
    private MavenProject project; 

    /** @parameter expression="${localRepository}" */ 
    protected ArtifactRepository m_localRepository; 

    /**@parameter default-value="${localRepository}" */ 
    private org.apache.maven.artifact.repository.ArtifactRepository 
     localRepository; 

    /** @parameter default-value="${project.remoteArtifactRepositories}" */ 
    private java.util.List remoteRepositories; 

    /** @component */ 
    private org.apache.maven.artifact.factory.ArtifactFactory artifactFactory; 

    /** @component */ 
    private org.apache.maven.artifact.resolver.ArtifactResolver resolver; 

सभी निर्भरता जार का संकल्प:

final List<Dependency> dependencies = project.getDependencies(); 

    for (Dependency d : dependencies) { 

     final Artifact artifact = 
      artifactFactory.createArtifactWithClassifier(d.getGroupId(), 
       d.getArtifactId(), d.getVersion(), d.getType(), 
       d.getClassifier()); 

     try { 
      resolver.resolve(artifact, remoteRepositories, 
        localRepository); 
     } catch (ArtifactResolutionException e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } catch (ArtifactNotFoundException e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 

     File artifactFile = artifact.getFile(); 
     System.out.println(artifactFile.getAbsolutePath()); 
    } 

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

-2

तेज़ी से किया जा सकता है/सुरक्षित/आसान सिर्फ प्लगइन config सूची कक्षाएं आप के आधार पर कोड जनरेट करना चाहते है। फिर आप इसे पोम में जोड़ते हैं और आप कर चुके हैं। कोई प्रतिबिंब की आवश्यकता नहीं है, और यह निश्चित रूप से प्लगइन के चलते तेजी से बढ़ जाएगा।

+0

यह विकल्प है जिसे मैं अंतिम उपाय के रूप में मानता हूं ... चूंकि मेरे पास इस इंटरफ़ेस को लागू करने वाले बहुत से वर्ग हैं और उन सभी को कोड जनरेशन में माना जाता है, मैं उन सभी को 'स्थिर रूप से' टाइप करना टालना चाहता हूं। साथ ही, इन कक्षाओं को अक्सर जोड़ा/हटा दिया जाता है। –

+0

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

1

<dependencies> अनुभाग में परिभाषित आर्टिफैक्ट निर्भरताएं हैं और <plugin><dependencies> के तहत परिभाषित प्लगइन निर्भरताएं हैं।

प्लगइन निर्भरता क्लासपाथ में जोड़ दी जाती है जबकि मुझे आर्टिफैक्ट निर्भरताओं के बारे में निश्चित नहीं है। क्या आपने <plugin><dependencies> के तहत अपनी प्लगइन निर्भरताओं को जोड़ने का प्रयास किया था?

+0

आपकी सलाह के मुताबिक, मैंने 'प्लगइन निर्भरता' जोड़ा है और अब यह क्लासपाथ मुद्रित (अजीब) के तहत दिखाई नहीं दे रहा है, लेकिन प्रतिबिंब पुस्तकालय MyInterface को ठीक से लागू करने वाले वर्गों का पता लगाता है! क्या प्लगइन निर्भरताओं में आर्टिफैक्ट निर्भरता शामिल करने का कोई तरीका है? मुझे पूरे खंड की कॉपी-पेस्टिंग से बचना अच्छा लगेगा:/ –

+1

@PiotrekDe शायद आप सभी जरूरी निर्भरताओं के साथ एक जार प्रोजेक्ट बना सकते हैं जिसका उपयोग आप पीओएम और प्लगइन दोनों के लिए निर्भरता के रूप में करेंगे। मुझे यकीन नहीं है कि यह दर्द के लायक है हालांकि ... –

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

  • कोई संबंधित समस्या नहीं^_^