Практика обеспечения сборки проектов Android сразу после проверки SVN в Eclipse

Проблема:

Когда проект регистрируется в SVN, а кто-то еще проверяет его, на нем появляется восклицательный знак, и необходимо устранить ошибки пути сборки. Как это исправить?

Например, у меня есть проект, и его структура следующая:

В папке libs есть 3 библиотеки:

* android-support-v4.jar
* bugsense3.2.2.jar
* gcm.jar

В папке зависимостей Android есть:

* annotations.jar

Справочные библиотеки имеют:

* gcm.jar

Частные библиотеки Android имеют:

* bugsense3.2.2.jar
* gcm.jar
* android-support-v4.jar

API Google [Android 2.2] имеет:

* android.jar
* maps.jar

Получается, что все, что мы помещаем в папку libs, автоматически добавляется в частные библиотеки Android, так ли это? Таким образом, их можно зарегистрировать в SVN, и когда кто-то другой проверит и соберет их, .jars в частных библиотеках Android просто укажут на его локальную рабочую область, так что это не проблема.

Однако annotations.jar в зависимостях Android и android.jar и maps.jar в API Google ссылаются на папку android-sdk на моем диске C:. Поэтому, когда кто-то еще проверяет весь мой проект, у него возникают проблемы со сборкой, которые им приходится решать с помощью Java Build Path.

Какова стандартная практика хранения всех библиотек в SVN таким образом, чтобы, когда новый разработчик приходит и проверяет проект, он просто строит, не возясь с настройками? Я подозреваю, что мы собираемся использовать систему управления сборкой, непрерывную интеграцию, сервер сборки и т. д. Так что я немного знаю об этом, но никогда не использовал это на практике, поскольку я никогда не работал в достаточно большой команде. . Если бы кто-нибудь был так любезен, чтобы дать мне именно то, что он использует (настоящие инструменты, такие как Maven, Gradle и т. Д.), Я был бы очень признателен!

Спасибо,

-V


person vkinra    schedule 22.06.2013    source источник
comment
Вы можете развернуть частные jar-файлы в репозиторий Maven в локальной файловой системе и зарегистрировать их в SVN. См.: stackoverflow.com/a/12980000/7507.   -  person noahlz    schedule 22.06.2013
comment
Я на самом деле не уверен, что вы имеете в виду. По моему вопросу, мое понимание процессов сборки слабое. В результате, я надеюсь, что кто-то сможет подробно описать, что делать и какие инструменты использовать. У меня такое ощущение, что многие инженеры-программисты, не знакомые с миром больших команд, CI, процессов сборки и т. д., сочли бы это чрезвычайно полезным!   -  person vkinra    schedule 23.06.2013
comment
Вы можете использовать этот подход, даже работая самостоятельно с git, github и Travis-CI. Большие команды тут ни при чем.   -  person noahlz    schedule 23.06.2013


Ответы (1)


В библиотеках, которые ADK добавляет к пути к классам, нет ничего особенного. Если вы хотите иметь возможность проверить все зависимости вашего проекта, вы можете скопировать указанные файлы jar в локальный каталог, а затем указать путь к ним вместо использования предоставленных групп библиотек. Поскольку у плагина для Android есть эта новая дурацкая система, которая автоматически добавляет вещи в каталог libs к вашему пути и к вашему apk, я бы не рекомендовал помещать туда эти другие jar-файлы. Обычно здесь мы создаем отдельную папку в svn с именем третья сторона или что-то в этом роде, а затем используем svn:externals для ссылки на необходимые файлы jar. Наличие единого общего места для хранения сторонних JAR-файлов упрощает управление версиями и конфигурацией.

Чтобы проиллюстрировать ситуацию немного яснее, вот как будет выглядеть репозиторий в качестве примера:

repo
    -android_project
        -trunk
            -your other project stuff (src, etc)
            -libs
                -android-support-v4.jar
                -bugsense3.2.2.jar
                -gcm.jar
            -third-party
                -annotations.jar (external)
                -android.jar (external)
                -maps.jar (external)
third-party
    -android
        -v_X.XX
            -annotations.jar
            -android.jar
            -maps.jar

В вашем реальном проекте Eclipse вы должны добавить материал из сторонних к пути вручную, а adk автоматически добавит материал из libs в путь.

ИЗМЕНИТЬ

Говоря о сравнении этого метода с Maven, первое, что я признаю, это то, что у меня нет огромного опыта работы с Maven. Из того, что я знаю об этом, я не думаю, что это полностью соответствует вашим критериям. Когда я использовал Maven, по умолчанию он загружал ваши зависимости в определенное место на машине, а не в ваше рабочее пространство. Чтобы заставить Eclipse подобрать эти зависимости, вам нужно было добавить свойство M2_HOME в вашу рабочую область, чтобы он мог правильно разрешать все пути. Было довольно легко настроить все это, потому что были команды mvn для автоматизации процесса, но для кого-то, кто не знаком с системой, это могло вызвать много путаницы и замедлить работу, когда новый разработчик начинает работу над проектом. Кроме того, большая проблема, с которой мы столкнулись, заключалась в том, что для этого требуется, чтобы зависимости хранились в каком-то центральном репозитории, что очень затрудняло работу в несвязанных областях.

Опять же, я не эксперт по Maven, поэтому примите то, что я сказал, с долей скептицизма, но по моему опыту, Maven отлично работает в среде с открытым исходным кодом, где подключение приветствуется и почти гарантируется, но не так много в среде с закрытым исходным кодом. Окружающая среда. Казалось, что это создало больше проблем, чем решило для нас, и поэтому так и не прижилось. Преимущество системы, описанной выше, заключается в том, что после проверки у вас есть единственная папка, содержащая все (кроме eclipse), необходимое для разработки и сборки проекта. Это позволяет очень легко приступить к работе на новой машине или в незнакомой среде.

Я скажу, что большим преимуществом, предоставляемым Maven, является согласованность. В системе, которую я описал, разработчик отвечает за каждый аспект настройки проекта. Это означает, что между разработчиками и проектами вы можете получить различия в том, как устроен ваш репозиторий svn. Один разработчик может назвать каталог «сторонним», в то время как другой может назвать его «открытым исходным кодом», или некоторые разработчики могут не использовать магистраль в своих проектах. Со временем эти мелочи могут накопиться и оставить ваш репозиторий в беспорядке. Поскольку Maven отвечает за макет проекта, вы можете быть уверены, что ваш репозиторий останется согласованным.

person TwentyMiles    schedule 24.06.2013
comment
Вопрос: У меня сложилось впечатление, что вы можете использовать Maven для управления зависимостями проекта. Я продолжаю слышать, что я должен просто использовать для этого плагин maven eclipse. У вас есть опыт в этом, как я уже сказал, я ищу лучшую отраслевую практику. В любом случае, я проверю ваше предложение, и если ответов нет, а ваш метод чист, я сразу же приму его. - person vkinra; 25.06.2013
comment
@vkinra Мой ответ на ваш комментарий оказался немного многословным, поэтому я отредактировал свой ответ, включив его вместо добавления еще одного комментария. - person TwentyMiles; 25.06.2013
comment
Я ценю длинный ответ и приму ответ. Однако, если кто-то может улучшить это, пожалуйста, добавьте к этому. Спасибо, Двадцать миль. - person vkinra; 25.06.2013