практики для обеспечения Android проектов строить сразу после SVN проверки в Затмении

Question

Проблема:

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

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

Он имеет 3 библиотеки в папке Libs:

* 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 

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

* android.jar 
* maps.jar 

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

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

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

Спасибо,

-V

Answer 1

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

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

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 к пути.

EDIT

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

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

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