Wie funktioniert Efeu: veröffentlichen Arbeit?

stimmen
24

Ich bin ganz bei Verlust, wie die Ameise Aufgabe Efeu: veröffentlichen funktionieren soll.

Ich würde erwarten, dass ich meine normalen Build zu tun, die ein Bündel von JAR-Dateien erstellt, dann würde ich die Gläser an die (lokalen) Repository schieben.

Wie kann ich angeben, von wo die eingebauten Gläser abzurufen, und wie würden diejenigen enden im Repository auf?

Aktualisieren:

<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>

dies tatsächlich funktioniert, ich habe nicht enthalten, der den Abruf vor.

Aber ich habe noch einige Probleme haben, nehme ich an drei Gläser veröffentlichen möchten, 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 ich welche Namen sollten sie bekommen angeben können. (Unter Verwendung des Fragments oben werden die Gläser immer nur utils.jar genannt).

Update 1:

Ich habe es (etwas) zu arbeiten, aber es fühlt sich immer noch nicht richtig. Irgendwie alle Übungen konzentrieren sich auf Abhängigkeiten von 3rd-Party-Projekten, sondern ein ebenso wichtiger Punkt für mich ist projektspezifische Abhängigkeiten zu behandeln.

Ich habe eine Reihe von Teilprojekten, die auf verschiedene Weise voneinander abhängig sind. Efeu Berücksichtigung veröffentlicht es ist mir nicht klar, wie zu beginnen.

  1. Wie gehe ich die erste Version? Ich habe eine gemeinsame Versionsnummer für alle Teilprojekte, um anzuzeigen, dass sie zusammengehören (kann 0,9 sagen). Daher sollte die erste Revision 0.9.0 sein, aber bisher nichts von meinen Projekten ist in meinem Repository. Wie erhalte ich Ivy diese Revisionsnummer zuzuweisen.

  2. Im Zuge der Entwicklung Ich will wieder die integrierten Dateien veröffentlichen, ohne bisher die Revisionsnummer zu ändern.

  3. Wenn ich mit meiner Arbeit fertig bin ich es zu einem gemeinsamen Repository schieben will (und erhöhen läßt die Revisionsnummer von 0.9.0 bis 0.9.1 sagen), was ist der empfohlene Ansatz, dies zu tun?

  4. Für eine tatsächliche Veröffentlichung mag ich Verteilungen mit Abhängigkeiten machen und ohne irgendwie denke ich, dass ich verschiedene Konfigurationen für das verwenden kann. Wie kann ich das zu meinem Vorteil?

Veröffentlicht am 09/12/2008 um 17:18
quelle vom benutzer
In anderen Sprachen...                            


4 antworten

stimmen
9

Sie müssen die „Resolver“ angeben. Etwas wie:

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

Es wird durch das Muster gesteuert. Diese Seite deckt es ziemlich gut. Es sieht aus wie Sie Ihr sein wollen:

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

Und Sie brauchen die drei Gläser als Artefakte in der ivy.xml Datei zu identifizieren. Etwas wie das:

<publications>
    <artifact name="utils"/>
    <artifact name="utils" type="source"/>
    <artifact name="utils" type="javadocs"/>
</publications>
Beantwortet am 09/12/2008 um 17:30
quelle vom benutzer

stimmen
4

Zuerst müssen Sie eine 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>

Die Info-Element und Publikationen Elemente in ivy.xml können Sie verschiedene Attribute auf den Efeu Elemente in build.xml überspringen.

Beachten Sie die $ {} project.revision in ivy.xml. Die Liegenschaft befindet sich Wert in build.xml gegeben, aber dies scheint gut zu funktionieren. Die Revision kann dann leicht, was Wert erforderlich ist (zB. Nightly Builds gegen lokale Builds).

Hier ist ein Beispiel, wie Sie Ihre Datei build.xml einrichten könnten

<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>

...
Beantwortet am 13/01/2012 um 17:28
quelle vom benutzer

stimmen
2

Sie nehme an, die laufen <ivy:deliver/>erste Aufgabe. Dies schafft eine ivy.xml Datei, die vom Ivy Repository verwendet werden kann.

Wenn Sie verwenden <ivy:publish>Sie angeben , auf welches Repository Sie veröffentlichen wollen , indem sie in der Angabe resolverParameter. Dies muss der Resolver Namen in Ihrer übereinstimmen ivy.settings.xmlDatei.

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

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

Wenn Sie die Versionsnummer der Datei ändern möchten, können Sie die Verwendung pubrevision Parameter der <ivy:publish>Aufgabe. Dies aktualisiert nicht die ivy.xml, sondern wird Ihre Gläser / Kriege auf die richtige Version veröffentlichen. Ich bevorzuge die Verwendung pubrevision Parameter der <ivy:deliver>Aufgabe und lassen Sie es die richtige erstellen ivy.xmlsowieso Datei. Dann <ivy:publish>wird die Revision in meiner verwenden ivy.xmlDatei.

Sie brauchen nicht zu tun <ivy:retrieve>. Immerhin laufen Sie einen Build neue Gläser zu schaffen, und sie sollten IRGENDWO in Ihrem Build sein. Andernfalls, wenn Sie nicht ein Glas oder Krieg zu schaffen , was versuchen Sie in Ihrem Ivy Repository zu veröffentlichen? Und wollen Sie sicherlich nicht etwas bereits in der Ivy - Repository abrufen nur um es zu veröffentlichen.


Meine Philosophie war schon immer , dass die Veröffentlichung ein CM - Aufgabe ist und nicht als Teil des Build - Verfahren durchgeführt werden sollte. So verwenden wir keine <ivy:deliver>oder <ivy:publish>.

Wir verwenden Artifactory als unsere Ivy Repository (und unsere Maven - Repository). Wir verwenden Jenkins als unseren kontinuierlichen Build - Server.

Was ich tue , ist haben die Entwickler machen pom.xmlDatei aus ihrer ivy.xmlüber die Datei <ivy:makepom>Aufgabe. Dies und die Build - Gläser / Kriege werden als unzulässig Artefakte in Jenkins gespeichert.

Wenn wir glücklich mit einem bestimmten Build sind und will , dass es in unserem öffentlichen Repository, verwende ich Jenkin des Task Erstellen Förderung einen bestimmten jar / Krieg mit seinem pom.xml in unsere Artifactory Repository zu fördern. Wir verwenden die mvn deploy:deploy-fileAufgabe , das zu tun.

Beantwortet am 28/08/2012 um 19:07
quelle vom benutzer

stimmen
0

Es ist wichtig zu erkennen, welche Efeu hier tut. Es ist das Kopieren nicht einfach Ihre Artefakt Gläser in die Efeu-Repository - es ist auch die entsprechenden „.ivy.xml“ Dateien zu erzeugen, die alle unterhalte jedes Ihrer Artefakte angeben.

Unter den Abdeckungen, die ivy:retrieveist Aufgabe Auslösung tatsächlich auch ein ivy:resolve. Wenn das Efeu: resolve auftritt, wird eine Datei auf dem lokalen Efeu Cache geschrieben (im .ivyOrdner user.home) , die angibt , wie die Auflösung passiert ist (. , Welche Revisionen, welche Module die Auflösung zu vervollständigen erforderlich waren) , wenn ivy:publishfestgestellt wird, dass die Auflösung Aufnahmen abgerufen aus dem Cache und verwendet , um die ivy.xml für Ihre Artefakte zu erzeugen.

Die größte Gefahr ich in dies zu tun gefunden habe , ist die Forderung , dass die ivy:resolveund ivy:publishbeiden Aufgaben mit dem gleichen Klassenlader geladen werden , wenn sie durch Ameise ausgeführt werden. Der einfachste Weg , um sicherzustellen , dass dies geschieht , ist die loaderRef auf taskdef Aufgaben zu verwenden. Zum Beispiel (beachten Sie die passende 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"/>
Beantwortet am 10/12/2008 um 07:10
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more