Comments 15
У меня так и не получилось нормально подружить Мавен с EDT для Eclipse. Все время вылазили какие-то глюки и особенности, которые приходилось обходить, и времени на это уходило много. Пришлось отказаться в пользу обычной сборки вручную.
0
у меня тоже не получилось подружить maven, в итоге использую ant.
0
пользую maven + idea, архетипы взял тут github.com/akquinet/android-archetypes
+1
Что за привычка появилась у авторов, написать 2 страницы текста, а самое ценное откладывать «на потом»?
+2
Никакой привычки, по моим расчетам, просто получается довольно большой объем, поэтому решил разбить на несколько частей
0
Дико плюсую, ладно бы в этой первой статье было хоть что-то ценное. Если уж делаете частями, то дайте сразу первую часть, а не вступление.
+1
Долго Вы статью готовили :D
0
Будет хорошо, если бы у Вас в примерах проект был с библиотечным проектом. Потому как в реальных проектах по любому один такой проект, да используется, а во всех туториалах этот вопрос не освещается. Однако этот вариант добавляет своей специфики в настройке CI для андроида.
0
если вы используете ant, вся специфика заключается в вызове android update lib-project
0
Хорошо, я подумаю. Кстати, в примерах к android-maven-plugin'у есть семплы с библиотечными проектами (Папка libraryprojects).
По поводу специфики, если честно, я никакой специфики для CI от этого не вижу. Библиотечный проект такая же зависимость как и любой другой jar, который вы объявляете в dependencies, только вместо jar указывается apklib. Что вы имели в виду под спецификой?
По поводу специфики, если честно, я никакой специфики для CI от этого не вижу. Библиотечный проект такая же зависимость как и любой другой jar, который вы объявляете в dependencies, только вместо jar указывается apklib. Что вы имели в виду под спецификой?
0
Я ant пользовался. Для примеров с ним не было библиотечных проектов.
Вообще, я наверно не очень правильное слово подобрал, не специфика, а аспекты, так сказать.
До того, как загнать проект в jenkins, я library-проекты в vcs не держал, когда же понадобилась автоматическая сборка, я не нашел ничего лучше, как загнать все эти проекты в папку libs и добавить в vcs, что, помоему не очень изящное и не очень корректное решение, не других вариатов я не нашел.
Ну и вообще не все так гладко проходило, я уже не помню точно что там за глюки были, честно говоря. Тот же project.properties например придется другой делать, и прописывать разные android.library.reference если расположение library-проектов в jenkins'е отличное от вашего проекта, etc…
Вообще, я наверно не очень правильное слово подобрал, не специфика, а аспекты, так сказать.
До того, как загнать проект в jenkins, я library-проекты в vcs не держал, когда же понадобилась автоматическая сборка, я не нашел ничего лучше, как загнать все эти проекты в папку libs и добавить в vcs, что, помоему не очень изящное и не очень корректное решение, не других вариатов я не нашел.
Ну и вообще не все так гладко проходило, я уже не помню точно что там за глюки были, честно говоря. Тот же project.properties например придется другой делать, и прописывать разные android.library.reference если расположение library-проектов в jenkins'е отличное от вашего проекта, etc…
0
нет, вы можете запускать скрипты на Jenkinse. можно выполнить android update для всех проектов и пути пропишутся автоматически.
мне тоже приходилось хранить library projects в системе контроля версий, но если вы пользуетесь git, то это можно обойти с помощью git submodules
мне тоже приходилось хранить library projects в системе контроля версий, но если вы пользуетесь git, то это можно обойти с помощью git submodules
0
Sign up to leave a comment.
Android — Сontinuous Integration. Часть 1