Wie funktioniert ivy:veröffentlichen?

Bin ich komplett auf Verlust, wie der ant-task ivy:veröffentlichen Sie funktionieren soll.

Ich würde erwarten, dass ich meine normalen erstellen, das schafft eine Reihe von jar-Dateien, dann würde ich schieben die Gläser auf den (lokalen) repository.

Wie kann ich festlegen, von wo aus Sie zum abrufen der integrierten Gläsern, und wie würden diese am Ende in das repository?

Update:

<target name="publish-local" description="--> Publish Local">
    <ivy:retrieve />
    <ivy:publish resolver="local" pubrevision="${release.version}" status="release" update="true" overwrite="true">
        <artifacts pattern="${dist.dir}/[organisation]-[module].[ext]" />
    </ivy:publish>
</target>

dieser tatsächlich funktioniert, und ich habe nicht das abrufen vor.

Aber ich habe noch einige Probleme, angenommen, ich möchte zu veröffentlichen, 3 Gläser, openscada-utils.jar, openscada-utils-sources.jar und openscada-utils-javadocs.jar als openscada-utils-0.9.2.jar, openscada-utils-0.9.2-sources.jar und openscada-utils-0.9.2-javadocs.jar

Es ist nicht ganz klar zu mir, wie die tatsächlichen Namen versammelt sind, und wo kann ich angeben, welche Namen Sie bekommen sollen. (Mit dem fragment oben, die Gläser sind immer aufgerufen, nur utils.jar).

Update 1:

Ich habe es auf Arbeit (ein bisschen), aber es noch nicht richtig fühlen. Irgendwie alle tutorials auf Abhängigkeiten von 3rd-party-Projekte, aber ein ebenso wichtiger Punkt für mich ist, zu behandeln projektspezifischen Abhängigkeiten.

Ich habe eine Reihe von sub-Projekte, die es bedingen einander in vielfältiger Weise. In Anbetracht ivy:veröffentlichen, es ist mir nicht klar, wie ich anfangen soll.

  1. Wie gehe ich mit der ersten version? Ich haben eine gemeinsame version für alle sub-Projekte, um anzugeben, dass Sie zusammen gehören (können sagen, 0.9). Deshalb ist die erste revision sollte 0.9.0, aber so weit nichts meiner Projekte ist in meinem repository. Wie bekomme ich Efeu an, ordnen diese Revisionsnummer.
  2. Im Zuge der Entwicklung, die ich veröffentlichen wollen, der integrierte Dateien wieder, ohne eine änderung der Revisionsnummer so weit.
  3. Wenn ich fertig bin mit meiner Arbeit möchte ich ihn drücken, um zu einem gemeinsamen repository (und Erhöhung der Revisionsnummer können sagen, von 0.9.0, 0.9.1), was ist die empfohlene Vorgehensweise, um dies zu tun?
  4. Für einen tatsächlichen release, ich will Distributionen mit Abhängigkeiten und ohne, irgendwie denke ich, ich kann verschiedene Konfigurationen. Wie kann ich dass zu meinem Vorteil nutzen?

InformationsquelleAutor der Frage Mauli | 2008-12-09

  1. 10

    Müssen Sie angeben, die "resolver". So etwas wie:

    <ivy:publish resolver="local" pubrevision="1.0"/>

    Gesteuert wird, durch das Muster. Diese Seite deckt es ziemlich gut. Es sieht aus wie Sie wollen, bei Ihnen zu sein:

    <artifacts pattern="${dist.dir}/[organisation]-[module]-[revision]-[type].[ext]" />

    Und Sie benötigen, um identifizieren die drei Gläser, die als Artefakte in die ivy.xml Datei. So etwas wie dieses:

    <publications>
    <artifact name="utils"/>
    <artifact name="utils" type="source"/>
    <artifact name="utils" type="javadocs"/>
</publications>

    InformationsquelleAutor der Antwort sblundy

  2. 4

    Zuerst müssen Sie ein ivy.xml Datei. 

    <ivy-module version="2.0">
    <info organisation="com.example.code" module="MyProject"
         revision="${project.revision}"/>
    <configurations>
        <conf name="runtime" description="" />
        ... other config elements here...
    </configurations>

    <publications defaultconf="runtime">
        <artifact name="MyProject" type="jar" ext="jar" conf="runtime" />
    </publications>

    <dependencies>
        ...
    </dependencies>
</ivy-module>

    Info-element und Publikationen-Elemente in ivy.xml erlauben Sie
    überspringen von verschiedenen Parametern auf die ivy-Elemente in build.xml.

    Beachten Sie die ${project.revision} ivy.xml. Die Eigenschaft ist gegeben Wert
    in build.xml, aber das scheint schön zu arbeiten. Die revision kann dann
    leicht zu haben, was Wert ist erforderlich, (zB. nightly builds vs. lokale builds).

    Hier ist ein Beispiel, wie könnte man einrichten build.xml Datei

    <property name="project.revision" value="1.0.0"/>

...

<target name="ivy">
    <ivy:resolve />

    <!-- Possible ivy:report, ivy:retrieve and other
    elements for managing your dependencies go here -->

    <ivy:deliver conf="*(public)"/> 
</target>

<target name="publish" depends="clean, ivy, jar">
    <ivy:publish resolver="local">
        <!-- possible artifacts elements if your artifacts
        are not in standard location -->
    </ivy:publish>
</target>

...

    InformationsquelleAutor der Antwort Peter Lamberg

  3. 2

    Du bist wohl zu laufen die <ivy:deliver/> Aufgabe zuerst. Dies schafft eine ivy.xml Datei, die verwendet werden können, von der Ivy-repository.

    Wenn Sie <ivy:publish> geben Sie das repository aus, das Sie veröffentlichen möchten, auf das durch die Angabe in der resolver parameter. Dieser muss übereinstimmen, den der resolver-Namen in Ihrem ivy.settings.xml Datei.

    Du nicht wirklich angeben, die Artefakte, sondern ein Muster, wo Sie die Artefakte zu veröffentlichen. Dies legen Sie über die <artifacts> Teilaufgabe auf die <ivy:publish> Aufgabe. Zum Beispiel, wenn Sie bauen alles unter der ${basedir}/target/archive Verzeichnis, wie wir es tun, können Sie es wie diese:

    <ivy:publish resolver="public">
   <artifacts path="target/archive/[artifact].[ext]"/>
</ivy:publish>

    Wenn Sie möchten, ändern die Revisionsnummer der Datei, die Sie verwenden können, die pubrevision parameter der <ivy:publish> Aufgabe. Aktualisiert dies nicht der ivy.xmlaber veröffentlichen Sie Ihre Gläser/Kriege, um die korrekte revision. Ich benutze lieber die pubrevision parameter der <ivy:deliver> Aufgabe und lassen Sie es schaffen die richtige ivy.xml Datei sowieso. Dann <ivy:publish> verwenden der revision in meinem ivy.xml Datei.

    Brauchen Sie nicht zu tun <ivy:retrieve>. Nachdem alle, Sie sind running ein build zu erstellen, neue Gläser, und Sie sollte IRGENDWO in deinem build. Ansonsten, wenn Sie nicht erstellen Sie eine jar-oder war das, was sind Sie versuchen zu veröffentlichen in Ihren Ivy-repository? Und Sie wollen sicher nicht, um etwas abrufen, die bereits in Ihren Ivy-repository, nur um erneut veröffentlichen.

    Meine Philosophie war schon immer, dass die Veröffentlichung eines CM-task und sollte nicht getan werden, als Teil des build-Verfahren. Also, wir verwenden nicht <ivy:deliver> oder <ivy:publish>.

    Verwenden wir Artifactory als unsere Ivy repository (und unserem Maven-repository). Wir verwenden Jenkins als unsere continuous-build-server.

    Was ich zu tun ist, haben die Entwickler eine pom.xml - Datei aus Ihren ivy.xml Datei über die <ivy:makepom> Aufgabe. Dies und die build-Gläser/Kriege werden gespeichert, archiviert Artefakte in Jenkins.

    Wenn wir glücklich sind mit einem bestimmten build und möchten es in unserem öffentlichen repository verwende ich Jenkin ist die Förderung der Build-Aufgabe zu fördern, insbesondere jar/war mit seiner pom.xml unsere Artifactory repository. Wir verwenden die mvn deploy:deploy-file Aufgabe, das zu tun.

    InformationsquelleAutor der Antwort David W.

  4. 0

    Ist es wichtig zu erkennen, was ivy hier tut. Es ist NICHT einfach so kopieren Sie Ihre Artefakt Gläser in die ivy-repository - es ist auch die Generierung der entsprechenden ".ivy.xml" Dateien anzugeben, dass alle Angehörigen der einzelnen Artefakte.

    Unter der Decke, die ivy:retrieve Aufgabe ist eigentlich auch die Auslösung einer ivy:resolve. Wenn ivy:resolve Auftritt, wird eine Datei geschrieben, um Ihre lokalen ivy-cache (in der .ivy Ordner in user.home), die angibt, wie die Auflösung geschah (die überarbeitungen, welche Module benötigt wurden, um eine vollständige Auflösung.) Wenn ivy:publish wird festgestellt, dass die Auflösung Datensatz aus dem cache abgerufen und verwendet, um generieren die ivy.xml für Ihre Artefakte.

    Die größte Gefahr, die ich gefunden habe, ist dabei die Voraussetzung, dass die ivy:resolve und ivy:publish tasks geladen werden, die von den gleichen classloader, wenn Sie ausgeführt werden, die von ant. Der einfachste Weg, um sicherzustellen, dass dies geschieht, ist die Verwendung der loaderRef auf Ihre taskdef-Aufgaben. Zum Beispiel (beachte die passenden loaderRef tags):

    <taskdef name="ivy-retrieve" 
     classname="org.apache.ivy.ant.IvyRetrieve" 
     classpathref="ivy.lib" 
     loaderRef="ivy.loader"/>
<taskdef name="ivy-publish" 
     classname="org.apache.ivy.ant.IvyPublish" 
     classpathref="ivy.lib" 
     loaderRef="ivy.loader"/>

    InformationsquelleAutor der Antwort Jared

Schreibe einen Kommentar