Jak bluszcz: opublikować pracę?

głosy
24

Jestem całkowicie na straty, jak mrówka bluszcz zadanie: publikują ma pracować.

Spodziewam się, że robię mój normalny build, który tworzy kilka plików jar, wtedy wciskam te słoiki do repozytorium (lokalnym).

Jak mogę określić, skąd pobrać wbudowanych słoiki, a jak by ci skończyć w repozytorium?

Aktualizacja:

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

to faktycznie działa, nie obejmują odzyskać wcześniej.

Ale wciąż mam pewne problemy, załóżmy, że chcę opublikować 3 słoiki openscada-utils.jar, openscada-utils-sources.jar i openscada-utils-javadocs.jar jak openscada-utils-0.9.2.jar, openscada-utils -0.9.2-sources.jar i openscada-utils-0.9.2-javadocs.jar

To nie jest do końca jasne dla mnie, jak rzeczywiste nazwy są zmontowane, i gdzie mogę określić nazwy powinny one dostać. (Przy użyciu fragmentu powyżej, słoiki zawsze wywołana tylko utils.jar).

Aktualizacja 1:

Dostałem go do pracy (trochę), ale nadal nie czuje się dobrze. Jakoś wszystkie ćwiczenia koncentrują się na zależności od projektów 3rd party, ale równie ważną kwestią jest dla mnie do obsługi konkretnych zależności projektowych.

Mam kilka cząstkowych projektów, które są zależne od siebie na różne sposoby. Biorąc pod uwagę, bluszcz: opublikowanie go nie jest dla mnie jasne, jak zacząć.

  1. W jaki sposób poradzić sobie z pierwszą wersję? I mają wspólny numer wersji dla wszystkich projektów cząstkowych, aby wskazać, że należą one razem (powiedzmy 0,9). Dlatego też pierwsza rewizja powinna być 0.9.0, ale jak dotąd nic z moich projektów jest w moim repozytorium. Jak mogę dostać Ivy przypisać ten numer rewizji.

  2. W trakcie opracowywania chcę ponownie opublikować wbudowanych plików, bez zmiany numeru wersji tej pory.

  3. Jeśli skończę mojej pracy chcę naciskać go do wspólnego repozytorium (i zwiększyć liczbę rewizja powiedzmy od 0.9.0 do wersji 0.9.1), co jest zalecane podejście to zrobić?

  4. W przypadku rzeczywistego uwolnienia, chcę dokonywać wypłat z zależnościami i bez, jakoś myślę, że mogę wykorzystać różne konfiguracje do tego. Jak mogę wykorzystać to na swoją korzyść?

Utwórz 09/12/2008 o 17:18
źródło użytkownik
W innych językach...                            


4 odpowiedzi

głosy
9

Trzeba określić „rozpoznawania nazw”. Coś jak:

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

Jest kontrolowany przez wzorzec. Ta strona obejmuje go całkiem dobrze. To wygląda tak, jak chcesz twoje być:

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

I trzeba zidentyfikować trzy słoiki jako artefakty w pliku ivy.xml. Coś takiego:

<publications>
    <artifact name="utils"/>
    <artifact name="utils" type="source"/>
    <artifact name="utils" type="javadocs"/>
</publications>
Odpowiedział 09/12/2008 o 17:30
źródło użytkownik

głosy
4

Najpierw trzeba plik ivy.xml.

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

Element informacji i publikacji elementy ivy.xml pozwalają pominąć różne atrybuty elementów bluszcz w build.xml.

Zwróć uwagę na $ {project.revision} w ivy.xml. Nieruchomość jest podana wartość w build.xml, ale to wydaje się działać dobrze. Korekta może wtedy łatwo mieć wartość co jest wymagane (np. Nightly buduje vs. lokalna buduje).

Oto przykład, jak można skonfigurować plik build.xml

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

...
Odpowiedział 13/01/2012 o 17:28
źródło użytkownik

głosy
2

Jesteś przypuszczać, aby uruchomić <ivy:deliver/>pierwsze zadanie. To tworzy plik ivy.xml które mogą być używane przez repozytorium Ivy.

Podczas korzystania <ivy:publish>określić, które przechowalni chcesz opublikować, określając ją w resolverparametrze. To musi być zgodna z nazwą programu rozpoznawania nazw w ivy.settings.xmlpliku.

Tak naprawdę nie określił artefakty, ale wzór gdzie znaleźć artefakty opublikować. Można określić to poprzez <artifacts>podzadania na <ivy:publish>zadania. Na przykład, jeśli budujemy wszystko w ramach ${basedir}/target/archivekatalogu tak jak my, można określić go jako to:

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

Jeśli chcesz zmienić numer wersji pliku, można użyć pubrevision parametr <ivy:publish>zadania. To nie aktualizuje ivy.xml, ale będzie publikować swoje słoiki / wars do właściwej wersji. Wolę używać pubrevision parametr <ivy:deliver>zadania i pozwolił stworzyć poprawny ivy.xmlplik tak. Następnie <ivy:publish>użyje rewizji w moim ivy.xmlpliku.

Nie trzeba robić <ivy:retrieve>. Po tym wszystkim, używasz kompilacji do tworzenia nowych słoików i powinny być gdzieś w swojej budowie. W przeciwnym razie, jeśli nie jesteś tworzenie słoik lub wojny, co starasz się opublikować w swoim repozytorium Ivy? I na pewno nie chcą odzyskać coś już w repozytorium Ivy żeby go opublikować.


Moja filozofia zawsze było, że wydawnictwo to zadanie CM i nie powinny być wykonywane jako część procedury wykonania. Tak więc, nie używamy <ivy:deliver>lub <ivy:publish>.

Używamy Artifactory jako repozytorium (Ivy i naszego repozytorium Maven). Używamy Jenkins jako naszego ciągłego serwera kompilacji.

Co mogę zrobić, to mieć deweloperzy zrobić pom.xmlplik z ich ivy.xmlpliku poprzez <ivy:makepom>zadania. To i słoiki Build / wars są zapisywane jako zarchiwizowanych artefakty w Jenkins.

Gdy jesteśmy zadowoleni z danej budowy i chcą go w naszym repozytorium publicznym, używam Jenkin Promujmy zadanie Konstruowanie, aby promować szczególne słoik / wojny z jego pom.xml do naszego repozytorium Artifactory. Używamy mvn deploy:deploy-filezadanie to zrobić.

Odpowiedział 28/08/2012 o 19:07
źródło użytkownik

głosy
0

Ważne jest, aby zdać sobie sprawę, co robi tutaj bluszcz. Nie jest to po prostu kopiując słoiki artefaktów do repozytorium bluszczu - jest również generowanie odpowiednich „.ivy.xml” pliki, które określają wszystkie utrzymaniu z każdego z przedmiotów.

Pod kołdrą The ivy:retrievezadaniem jest faktycznie również wyzwalania ivy:resolve. Kiedy ten bluszcz: występuje postanowienie, plik jest zapisywany na lokalnej pamięci podręcznej bluszczu (w .ivyfolderze user.home), która określa, jak się rozdzielczość (. Który nowelizacje, które moduły były wymagane do ukończenia rozdzielczość) Po ivy:publishnapotkaniu, że rekord rozdzielczość to pobierane z pamięci podręcznej i wykorzystywane do generowania ivy.xml dla swoich artefaktów.

Największą pułapką Znalazłem w ten sposób jest wymóg, że ivy:resolvei ivy:publishzadania zarówno być ładowany przez tego samego classloader, gdy są one wykonywane przez mrówki. Najprostszym sposobem, aby upewnić się, że tak się stanie jest użycie loaderRef na swoim taskdef zadań. Na przykład (uwaga tagów dopasowanie loaderRef):

<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"/>
Odpowiedział 10/12/2008 o 07:10
źródło użytkownik

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