Da das ganze nicht sinnvoll mit mvn:release gemacht werden kann, wollte ich den „manuellen“ Weg gehen, wie er auch in Manual Staging Bundle Creation and Deployment beschrieben ist: Alles in eine riesen JAR zusammenpacken und Sonatype das ganze dann auseinanderpflücken lassen.
So weit so frickelig. Nachdem ich mir einen Haufen BAT-Dateien geschrieben habe (die Maven-Puristen zum Weinen bringen würden ) dämmerte mir auf einmal:
Die native libraries liegen in Dateien wie
jcublas-natives-0.8.0-windows-x86_64.jar
wobei die Struktur is:
artifactId: „jcublas-natives“
version: „0.8.0“
classifier: „windows-x86_64“
Nun will Maven aber unbedingt „sources“ und „javadoc“ dabei haben. Erstens gibt es die nicht (da ist ja nur eine DLL drin), und zweitens ist „classifier“ ja schon belegt…
Hat jemand eine Idee?
*** Edit ***
(Ich nehme an, dass leere JARs nach dem Muster
jcublas-natives-0.8.0-soruces.jar
die Lösung sind - aber irgendwie sieht das seltsam aus…)
Das mit den leeren JARs könnte gehen. Aber mit den POMs gibt es ein Problem.
Jedes der 16 artifacts braucht eine POM. Natürlich hat jedes schon eine. Aber sie brauchen jeweils eine spezielle, und zwar nur für’s deployment (also für das Erstellen der bundle.jar). Der Unterschied wäre
In der deployment-POM sind die Build-Infos weggelassen
In der deployment-POM stehen die developer/name/scm/license Sachen drin, die Maven braucht
Und letzteres eben 16 mal (!). Einerseits könnte man die in die Parent-POM packen, aber das kommt dann ja nicht in der bundle.jar an…
[quote=Marco13]Nun will Maven aber unbedingt “sources” und “javadoc” dabei haben. Erstens gibt es die nicht (da ist ja nur eine DLL drin)[/quote]Ist die DLL “3rd party”?
wenn nicht, dann gibt es doch sourcen, halt nicht für java…
und “Javadoc” ist letztlich nichts anderes als eine hand voll HTML-Dateien mit beschreibungen. Ich verstehe gerade nicht, warum es die nicht auch für DLLs geben sollte (außer, dass man sie per Hand schreiben müsste).
Die DLL ist alles andere als 3rd party. Die sourcen da irgendwie mit reinzuwursten hatte ich zwar in Betracht gezogen, aber das würde den Build-Prozess noch etwas aufwändiger machen. (Das würde ich dann eher für Version 0.9.0). Hab’s zwar mal als issue unter Attach sources for native libraries in Maven build · Issue #15 · jcuda/jcuda-main · GitHub aufgenommen, aber der Nutzen davon wäre doch recht eingeschränkt. Aber spätestens JavaDocs machen keinen Sinn. Ich werde jedenfalls NICHT noch Doxygen über den C-Teil laufen lassen Das ist ja ohnehin genau das, was der Benutzer der Library nicht sehen sollte.
Wegen der POMs: Ich bin mir ziemlich sicher, dass es irgendein magisches mvn pomRefactor:inlineParentPom ...
gibt, mit dem man die „scm/name/…“ infos aus der Parent-POM in die Unter-POMs ziehen könnte. Aber ein komplettes inlinen würde die POMs riesig machen und tonnenweise Infos enthalten, die gar nicht benötigt werden…
Du kannst durchaus verschiedene classifier nutzen: Das ist nicht begrenzt…
jcublas-natives-0.8.0-windows_x86_64.jar
jcublas-natives-0.8.0-windows_x86_62.jar
jcublas-natives-0.8.0-i586.jar
jcublas-natives-0.8.0-x86_64.jar
jcublas-natives-0.8.0-xyz.jar
Gruß
Karl Heinz Marbaise
*** Edit ***
Hallo,
Na gut über das was ein Nutzer sehen sollte ist eine andere Frage wenn das in Maven Central drin ist…
[QUOTE=Marco13;144843]
Wegen der POMs: Ich bin mir ziemlich sicher, dass es irgendein magisches mvn pomRefactor:inlineParentPom ...
gibt, mit dem man die „scm/name/…“ infos aus der Parent-POM in die Unter-POMs ziehen könnte. Aber ein komplettes inlinen würde die POMs riesig machen und tonnenweise Infos enthalten, die gar nicht benötigt werden…[/QUOTE]
Die Magie nennt sich parent POM und Vererbung…eben am Besten mit einem eigenen separaten Parent POM Projekt wo dann alles drin ist was vererbt werden soll. Die SCM Information eben für jedes Projekt, da es auch separate Git Repos sind…
Der Punkt mit den classifiern ist ja eigentlich erledigt: Die -natives-artifacts haben ja eigentlich keine JAR, die keinen classifier hat. Inzwischen haben sie eine, weil Maven die braucht. Es ist also jetzt so angedacht:
jcuda-natives-0.8.0.jar // Leer
jcuda-natives-0.8.0-sources.jar // Leer (bisher, später kommt da ggf. der native code rein)
jcuda-natives-0.8.0-javadoc.jar // Leer (Da irgendeine Doxgen-Doku reinpacken wäre IMHO ziemlich sinnlos)
jcuda-natives-0.8.0-windows_x86_64.jar // Da ist das eigentliche “meat” drin…
…
package org.jcuda.test;
import jcuda.Pointer;
import jcuda.driver.CUdeviceptr;
import jcuda.driver.JCudaDriver;
import jcuda.jcublas.JCublas2;
import jcuda.jcudnn.JCudnn;
import jcuda.jcufft.JCufft;
import jcuda.jcurand.JCurand;
import jcuda.jcusolver.JCusolver;
import jcuda.jcusparse.JCusparse;
import jcuda.nvrtc.JNvrtc;
import jcuda.runtime.JCuda;
public class JCudaMavenTest
{
public static void main(String[] args)
{
// Call a method in all libraries, to
// spot the UnsatisfiedLinkError...
JCuda.setExceptionsEnabled(true);
JCudaDriver.setExceptionsEnabled(true);
JCublas2.setExceptionsEnabled(true);
JCufft.setExceptionsEnabled(true);
JCurand.setExceptionsEnabled(true);
JCusolver.setExceptionsEnabled(true);
JCusparse.setExceptionsEnabled(true);
JNvrtc.setExceptionsEnabled(true);
// For this, the cuDNN library is required
// in the project directory!
//JCudnn.setExceptionsEnabled(true);
// Do some basic operations
Pointer p = new Pointer();
JCuda.cudaMalloc(p, 4);
System.out.println("Pointer: "+p);
CUdeviceptr d = new CUdeviceptr();
JCudaDriver.cuMemAlloc(d, 4);
System.out.println("CUdeviceptr: "+d);
}
}
) dämmerte mir auf einmal: