Generare il mapping XML di una ricerca di directory ricorsiva

Question

Sto leggendo un elenco che ha un numero elevato di archivi sotto determinati componenti. ad es.

component1:filelocation1/a11.ear 
component1:filelocation1/a12.ear 
component2:filelocation2/a2.ear 
component3:filelocation3/a3.ear 
component4:filelocation3/basefile.properties 

ho bisogno di decomprimere ogni archivio in modo ricorsivo fino all'ultimo livello di dati e generare un file di mapping XML catturare la mappatura corretta dal componente per l'ultimo elemento in archivio.

struttura del documento XML di cui sarebbe come:

<my-app> 
    <mapping> 
    <toplevel loc="filelocation1" filename="a11.ear" component="component1"> 
     <childlevel loc="." filename="x1.war"> 
      <childlevel loc="WEB-INF/classes" filename="abc1.class"/> 
      <childlevel loc="WEB-INF/classes" filename="abc2.class"/> 
     </childlevel> 
    </toplevel> 
    <toplevel loc="filelocation1" filename="a12.ear" component="component1"> 
     <childlevel loc="." filename="x2.jar"> 
     <childlevel loc="org/test" filename="abc1.class"/> 
     <childlevel loc="org/test" filename="abc2.class"/> 
     </childlevel> 
     <childlevel loc="." filename="x3.war"> 
      <childlevel loc="WEB-INF/lib" filename="web1.jar"> 
      <childlevel loc="org/test" filename="abc1.class"/> 
     </childlevel> 
     <childlevel loc="WEB-INF/classes" filename="abc2.class"/> 
     </childlevel> 
    </toplevel> 
    </mapping> 
    </my-app> 

Qual è il miglior appraoch per farlo? Sto considerando l'utilizzo di un parser DOM per generare l'XML.

Answer 1

Lo farei utilizzando gradle.

Gradle ha delle belle strutture integrate per gli archivi di disimballaggio. È possibile utilizzare groovy (fornito con gradle) per l'analisi/generazione XML, che sarà molto più pulito rispetto all'utilizzo di una libreria XML Java.

Answer 2

Poiché i file JAR sono anche file ZIP, se si sta per farlo in Java, utilizzare la libreria java.util.zip. Anche se sarà comunque necessario aprire ricorsivamente tutti i JAR incorporati in WAR ed EAR, ciò ti farà risparmiare la fatica di passare attraverso le directory contenenti file flat. È inoltre possibile utilizzare la sottoclasse JarFile del file Zip offerto dalla libreria java.util.zip.

http://docs.oracle.com/javase/6/docs/api/java/util/zip/ZipFile.html

anche io probabilmente non mi preoccuperei con un parser DOM solo per la stampa di XML. Costruiresti una (potenzialmente grande) struttura in memoria quando invece potresti stampare i dati su un flusso mentre vai. Inoltre, i parser servono per analizzare l'XML in una struttura dati, non viceversa. Le classi di parsing Java DOM standard, javax.xml.parsers.DocumentBuilderFactory e javax.xml.parsers.DocumentBuilder non vengono fornite con un comando "print". Il modo standard per creare output di testo formattato da un oggetto org.w3c.dom.Document è quello di utilizzare un trasformatore XSL (vedere http://java.sun.com/webservices/reference/tutorials/jaxp/html/xslt.html#gghkq) e, di nuovo, è probabilmente più un problema che non ne vale la pena. Suppongo che dipenda da quanto vuoi estendere questo programma, ma se quello che hai qui è tutto ciò che deve fare, non vorrei costruire un grosso oggetto DOM.