Come distribuire il bundle OSGi su repository Maven con deploy: deploy-file?

Question

Ho un bundle OSGi che è stato creato usando Maven da un'altra squadra. Il file POM dichiara la sua confezione come "pacchetto" e utilizza il plugin Apache Felix.

Ho bisogno di distribuire questo artefatto in un repository Maven locale (Nexus) in modo che possa essere utilizzato dai nostri progetti interni.

Ho utilizzato la destinazione deploy:deploy-file per distribuire il pacchetto nel repository, proprio come si farebbe con un file JAR standard e questo funziona senza errori. Ho estratto il POM incorporato dal fascio e passai che sulla linea di comando, in modo che la linea di comando era:

mvn deploy:deploy-file -Dfile=3rdpartybundle.jar -DpomFile=pom.xml -DrepositoryId=internal -Durl=http://internalserver/nexus 

Il problema è che dopo aver distribuito in questo modo, la confezione è impostato per raggruppare e come risultato il nome del manufatto nel repository finisce con un'estensione .bundle, invece che con un'estensione .jar.

Ora, non riusciamo a capire come dichiararlo come una dipendenza. Se lo dichiariamo in questo modo:

 <dependency> 
      <groupId>...</groupId> 
      <artifactId>...</artifactId> 
      <version>...</version> 
      <type>bundle</type> 
     </dependency> 

Viene visualizzato un errore che indica che la dipendenza non può essere risolta. La cosa interessante è che le coordinate GAV nel messaggio di errore hanno effettivamente "jar" come valore per il tipo di dipendenza anche se lo impostiamo come "bundle".

Se cambiamo la dipendenza a:

 <dependency> 
      <groupId>...</groupId> 
      <artifactId>...</artifactId> 
      <version>...</version> 
      <type>jar</type> 
     </dependency> 

Otteniamo lo stesso errore di dipendenza irrisolta esatto.

Quindi, come si suppone di distribuire un artefatto confezionato come pacchetto in un repository Maven, in modo che possa essere utilizzato come dipendenza dal tempo di compilazione per un altro progetto?

Grazie

Answer 1

Grazie per le risposte, penso di avere una soluzione (non la chiamerei una soluzione anche se).

@earcar è sulla strada giusta, sebbene tale soluzione non sfrutti tutte le informazioni disponibili nel pom.xml già disponibile nel pacchetto di terze parti (in particolare le dipendenze).

Quindi cosa sembra funzionare, anche se la documentazione per il deploy: distribuire-file è un po 'vago, è che si può passare un file pom.xml E impostare anche il parametro di confezionamento, allo stesso tempo. Così la mia linea di comando ora si presenta così:

mvn deploy:deploy-file -Dfile=3rdpartybundle.jar -DpomFile=pom.xml -DrepositoryId=internal -Durl=http://internalserver/nexus -Dpackaging=jar 

Facendo in questo modo, il pom.xml nel repository dice ancora che l'imballaggio è di tipo "fascio", e comprende tutte le dipendenze, ecc, ma lo stesso artefatto ha un'estensione di file .jar.

Poi quando dichiariamo la nostra dipendenza come tipo JAR, Maven è in grado di risolvere con successo:

<dependency> 
     <groupId>...</groupId> 
     <artifactId>...</artifactId> 
     <version>...</version> 
     <type>jar</type> 
    </dependency> 

questo risolve fondamentalmente il nostro problema. Non sono sicuro di quanto sia portatile o affidabile. FWIW, stiamo eseguendo Maven 3.0.3

Grazie per l'aiuto.

Answer 2

Si consiglia di provare la rimozione del tipo completamente, e poi fare un semplice

mvn install 

Nella directory che contiene il file pom.xml.

Answer 3

Inizialmente, si è tentato di richiamare semplicemente mvn deploy nella cartella del pacchetto. Mi aspetto che il bundle diventi, generato, testato e distribuito se distributionManagement è configurato per la distribuzione sul tuo nesso.
Se ciò non riesce, è possibile importare manualmente il pacchetto utilizzando l'interfaccia Web nexus in un repository ospitato.

Answer 4

Il problema è che "3rdpartybundle.jar" si sta costruendo senza impostare estensioni = true e/o supportati tipi:

<plugin> 
    <groupId>org.apache.felix</groupId> 
    <artifactId>maven-bundle-plugin</artifactId> 
... 
    <extensions>true</extensions> 
... 
    <configuration> 
     <supportedProjectTypes> 
      <supportedProjectType>jar</supportedProjectType> 
      <supportedProjectType>war</supportedProjectType> 
     </supportedProjectTypes> 

Se non è possibile risolvere il problema che a monte, poi ci sono un paio di opzioni;

1) Reimballare come un vaso con un nuovo progetto di pom:

    <plugin> 
          <groupId>org.apache.maven.plugins</groupId> 
          <artifactId>maven-dependency-plugin</artifactId> 
          <version>2.3</version> 
          <configuration> 
            <actTransitively>false</actTransitively> 
            <outputDirectory>target/classes</outputDirectory> 
            <artifactItems> 
              <artifactItem> 
                <groupId>3rd</groupId> 
                <artifactId>party</artifactId> 
                <version>X.Y.Z</version> 
              </artifactItem> 
            </artifactItems> 
          </configuration> 
          <executions> 
            <execution> 
              <goals> 
                <goal>unpack</goal> 
              </goals> 
              <phase>compile</phase> 
            </execution> 
          </executions> 
        </plugin> 

2) Provare a utilizzare mvn deploy:deploy-file con -DgeneratePom=false -Dpackaging=jar -Dfile=/path/to/3rdpartybundle.jar ma senza specificare -DpomFile= - spero non c'è META-INF/Maven/pom.xml all'interno del 3rdpartybundle.jar - dovrebbe funzionare usando questo, ma dovrai specificare i parametri groupId/artifactId/version in quanto questi non saranno derivati ​​dal pom del progetto.

So che ho creato artefatti di bundle in passato e li ho implementati nel nostro nesso (v1.9.0.1) e quelli nel repository Spring sono stati inseriti anche in bundle, ma non ricordo alcun problema. (Per inciso non è necessario specificare il bundle nelle dichiarazioni di dipendenza, AFAIK se è l'unico artefatto che dovrebbe essere dedotto)