Что такое сборка проекта
Пожалуйста объясните, что такое сборка на простом примере
Здравствуйте товарищи специалисты. Почитал статейки про сборки, и ни как в голове не укладывается, что это такое. Вот например есть ехе файл моей программы, у него есть ресурс в виде иконок. Говорят что это уже сборка, тогда из чего она состоит?
Мне кажется что это ехе файл, с точкой входа и описанием необходимых библиотек (с описанием GUI). Но сама сборка называется сборкой только в момент работы ее в памяти. то есть области памяти, в которой лежит мой экзешник и скопированные в эту область памяти необходимые мне компоненты.
И кстати, каком образом моя программа находит необходимые мне компоненты по GUI, ведь записей в реестре больше не делается?
Поправте меня пожалуйста если я ошибаюсь.
P.S. Пожалуйста не отсылайте меня на читание статеек.
Объясните, пожалуйста, создание экземпляра класса в примере
Добрый день, имеем пример кода: using System; // Абстрактный класс может быть унаследован от.
Что такое стек, объясните подробно на примере Delphi
Ну в общем я объявляю указатель на переменную например a: integer; ukaz: ^a; понимаю что для.
Сборки могут содержать один или несколько модулей. Например, крупные проекты могут быть спланированы таким образом, чтобы несколько разработчиков работали каждый над своим модулем, а вместе эти модули образовывали одну сборку. Дополнительные сведения о модулях см. в разделе Практическое руководство. Создание многофайловой сборки.
Сборки имеют следующие свойства.
-Сборки реализованы как EXE- или DLL-файлы.
-Сборки можно поместить в глобальный кэш сборок, чтобы обеспечить их использование несколькими приложениями. В глобальный кэш сборок могут быть включены только сборки со строгими именами. Дополнительные сведения см. в разделе Сборки со строгими именами.
-Сборки загружаются в память только по мере необходимости. Если сборки не используются, они не загружаются. Благодаря этому сборки обеспечивают эффективное управление ресурсами в крупных проектах.
.
немного обобщая можно сказать, что сборка это приложение состоящее из нескольких исполняемых файлов (модулей), один из них exe, остальные dll.
Сборки имеют следующие свойства.
Сборки реализованы как файлы EXE или DLL.
Сборки загружаются в память только в том случае, если они реально используются. Если они не используются, то они не загружаются. Благодаря этому свойству сборки могут быть эффективным средством для управления ресурсами в крупных проектах.
Сведения о сборке можно получить программным путем с помощью отражения. Дополнительные сведения см. в статьях Отражение (C#) и Отражение (Visual Basic).
Сборки в среде CLR
Сборки предоставляют сведения для среды CLR, которые нужны для распознавания реализаций типов. Для среды выполнения тип не существует вне контекста сборки.
Сборка определяет следующие сведения:
Граница безопасности. Сборка представляет собой единицу, для которой запрашиваются и предоставляются разрешения. Дополнительные сведения о границах безопасности в сборках см. в разделе Вопросы безопасности сборок.
Граница области действия ссылок. Манифест сборки содержит метаданные, используемые для разрешения типов и для выполнения связанных с ресурсами запросов. Манифест указывает типы и ресурсы, предоставляемые за пределами сборки, а также перечисляет другие сборки, от которых она зависит. При отсутствии связанного манифеста сборки код на промежуточном языке MSIL, находящийся в переносимом исполняемом (PE) файле, выполняться не будет.
Граница версий. Сборка является наименьшей единицей с поддержкой версий в среде CLR. Версия для всех типов и ресурсов в одной сборке назначается как единому целому. В манифесте сборки описываются зависимости определенных версий от других сборок. Дополнительные сведения об управлении версиями см. в разделе Управление версиями сборки.
Единица развертывания. При запуске приложения могут присутствовать лишь сборки, первоначально вызываемые приложением. Другие сборки, например, содержащие ресурсы локализации или вспомогательные классы, могут извлекаться по требованию. Это позволяет приложениям сохранять простую структуру и малый размер при первоначальном скачивании. Дополнительные сведения о развертывании сборок см. в разделе Развертывание приложений.
Единица параллельного выполнения. Дополнительные сведения о выполнении нескольких версий сборок см. в разделе Сборки и параллельное выполнение.
Создание сборки
Сборки могут быть статическими или динамическими. Статические сборки хранятся на диске в виде переносимых исполняемых (PE) файлов. Статические сборки могут включать интерфейсы, классы и ресурсы, такие как точечные рисунки, файлы JPEG и другие файлы ресурсов. Кроме того, можно создавать динамические сборки, которые запускаются непосредственно из памяти и не сохраняются на диск перед выполнением. Динамические сборки можно сохранить на диске после выполнения.
Существует несколько способов создания сборок. Можно использовать средства разработки, такие как Visual Studio, позволяющие создавать файлы DLL или EXE. Чтобы создать сборки с использованием модулей из других средств разработки, можно воспользоваться средствами из Windows SDK. Для создания динамических сборок также можно использовать интерфейсы CLR такие, как System.Reflection.Emit.
Чтобы создать сборку в Visual Studio, выберите пункт Сборка в меню Сборка.
Манифест сборки
Каждая сборка имеет файл манифеста сборки. Манифест сборки выполняет роль оглавления и содержит следующее:
Идентификатор сборки (ее имя и версию).
Таблица с описанием всех файлов, входящих в сборку. Например, сюда относятся другие ваши сборки, от которых зависит файл EXE или DLL, а также растровые изображения или файлы сведений.
Добавление ссылки на сборку
Чтобы использовать сборку в приложении, нужно добавить ссылку на нее. Когда вы добавите ссылку на сборку, в вашем приложении станут доступны все предоставленные в сборке типы, свойства, методы и другие члены пространств имен, как если бы их код являлся частью файла с исходным кодом вашего приложения.
На C# вы можете использовать две версии одной и той же сборки в одном приложении. Дополнительные сведения см. в разделе Псевдоним extern.
Как собрать простейшую Java программу с помощью Maven
Статья написана для тех, кто умеет писать простейшие программы на java, но не умеет их собирать. Этим людям уже известно, что такое классы, что такое пакеты и зачем нужен public static main(String[] argv), но код без среды разработки они не запускали, да и не понимают кому и зачем это вообще может понадобиться.
Сразу скажу, что Java программиста, который не может собрать свою программу из консольки, на работу не возьмут, и это в общем более чем достаточная причина, чтобы научиться искусству обращения с системами сборки. Остальное детали, которым и посвящена статья.
Я принципиально не буду обсуждать в статье ничего, кроме сборки минимального HelloWorld. Также я постараюсь опустить все технические детали, которые можно опустить и подробно раскрыть всё, без понимания чего обойтись нельзя.
Для того, чтобы воспользоваться информацией из статьи нужно знать, что такое xml, переменные окружения, зачем нужна переменная окружения PATH и как пользоваться консолью.
Зачем собирать код без IDE
Первый вопрос, который возникает у начинающего разработчика — как в реальной жизни может пригодиться умение собирать код без среды разработки. Она ведь установлена и настроена у всех — это первое, что делает программист, когда приходит на проект.
Ответ простой — для того, чтобы нормально организовать рабочий процесс — код нужно регулярно собирать, проверять что он вообще компилируется, а потом, для того чтобы убедиться в работоспособности кода, прогонять тесты.
Можно, конечно, выделить специального человека, который будет раз в 15 минут запускать IDE и проводить описанные выше процедуры, но это безумие, такие вещи следует делать автоматически.
Уметь собирать код без среды разработки — суровая необходимость. Настолько суровая, что для решения этой задачи существует особый класс программного обеспечения, называемого системами сборки.
Что такое система сборки?
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, а на выход выдаёт программу, которую уже можно запустить.
Чем она отличается от компилятора? Если коротко, то система сборки вызывает компилятор при своей работе, а компилятор о существовании системы сборки даже не подозревает.
Если более длинно, то сборка, помимо компиляции, включает в себя ещё целый спектр задач, для решения которых компилятор не пригоден от слова совсем.
Например, если программе для работы нужны какие-нибудь картинки, то положить их в директорию с программой — задача системы сборки. Если программе нужны сторонние библиотеки, то положить их в директорию с программой — задача системы сборки. Ну и так далее.
И да, если автоматическая сборка проекта настроена и работает, то нет нужды вручную конфигурировать IDE — современная среда разработки сгенерирует проект самостоятельно, достаточно показать ей где находится конфигурация для системы сборки.
Систем сборки для java по большому счёту 3 — ant, maven и gradle. ant отживает свой век, нынче его используют либо ретрограды, либо реально крутые чуваки, типа Антона Кекса, gradle пока удел хипстеров, а вот maven — стандарт индустрии. Уметь им пользоваться просто необходимо.
Как установить maven
Maven устанавливается просто копированием в нужную директорию — никакого инсталлера нет. Как и в случае с большинством консольных утилит для использования достаточно добавить директорию maven/bin в переменную окружения PATH.
То есть, если maven находится в d:/soft/maven, то в PATH надо добавить d:/soft/maven/bin
Ещё для работы maven потребует переменную JAVA_HOME, которая указывает на JDK. Если JDK находится в C:/Program Files/Java/jdk1.8.0_05, то именно такое значение нужно поместить в JAVA_HOME. Добавлять bin в конец не нужно.
После этого можно попробовать написать в консоли
Если получится, значит maven установлен.
Как структурировать проект для maven
В терминологии maven совокупность файлов с исходным кодом программы, файлов настроек и всего такого называется проектом. Директория, в которой располагаются эти файлы, называется корневой директорией проекта. В дальшейшем я буду обозначать эту директорию как
Как известно, язык программирования java навязывает программисту структуру директорий, которая диктует расположение файлов с классами. Напимер класс с полным именем com.app.HelloWorld должен находиться в файле com/app/HelloWorld.java и никак иначе.
Maven добавляет к этому ограничению ещё одно — исходный код должен находиться в директории
/src/main/java. То есть класс com.app.HelloWorld maven будет искать в
Вот как будет выглядеть этот самый HelloWorld
Как сделать описание проекта
Содержимое минимального файла pom.xml будет примерно следующим. Для прохождения туториала можно таким его и оставить, если ничего не поменять, код нормально соберётся.
Что тут было существенно важного и что надо запомнить? Запомнить надо вот эти три строки.
Эти три строки являются идентификатором программы для внешнего мира. Программа, она же результат работы по сборке проекта, в терминологии maven называется артефактом.
Непонятное слово артефакт используется здесь вместо понятного слова программа потому, что результатом работы системы сборки может быть не только собственно программа, но и библиотека или ещё что-нибудь эдакое. Комбинация параметров groupId, artifactId и version уникальна для каждого артефакта. Об уникальности этой комбинации должен позаботиться программист.
Технически, значения этих параметров могут быть любыми, но при их выборе строго рекомендуется соблюдать правила хорошего тона.
groupId
В groupId обычно находится название какого-нибудь пакета. Напомню, что название пакета согласно тем же правилам хорошего тона, должно быть именем веб-домена, владельцем которого является автор пакета, что позволяет худо-бедно обеспечить уникальность названия.
artifactId
В artifactId — строка с именем артефакта, которое придумывает его создатель. Как правило это какое-нибудь слово, иногда с разделителями в виде тире. Например hibernate-annotation-wat. artifactId должны быть уникальны в рамках groupId.
version
Ну и наконец version это версия артефакта, которую надо увеличивать при каждом более-менее значительном изменении. Версия обычно включает цифрры и буквы. Типа 1.0-SNAPSHOT
Как собрать проект
Теперь, когда структура файлов проекта соответствует ожидаемой, а его описание присутствует в файле pom.xml, для того, чтобы собрать проект, осталось только открыть консоль, сменить текущую директорию на директорию проекта и написать в консоли:
После того, как maven закончит свою работу, в директории проекта появится директория target, в которой будет находиться скомпилированный код.
Скомпилированный java код выглядит так же, как исходный, только вместо файлов с расширением java в директориях, соответствующих названиями пакетов, находятся файлы с расширением class, в которых будет уже не исходный код, а код, предназначенный для интерпретации джава-машиной.
То есть теперь этот код можно запустить.
Как запустить проект
Чтобы запустить скомпилированный код, нужно в консоли из этой же директории набрать
После того, как maven перестанет качать всякую дрянь из интернета, где-то перед здоровой табличкой с надписью BUILD SUCCESS, появится строчка Hello World.
Код отработал, всё прошло удачно.
Вот так собирают java программы с помощью системы сборки maven.
Итого
maven ищет код для сборки в директории
Инструкции по сборке maven будет искать в
Результат работы системы сборки называется артефактом.
От программиста требуется задать groupId, artifactId и version
Сборка осуществляется командой mvn compile
Скомпилированный java код выглядит так же, как исходный код, но вместо файлов с расширением java, там будут файлы с расширением class.
Что такое сборщик продукта
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Поднять его на сервере приложения
Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.
Содержание
Что это такое и зачем он нужен
Вася решил стать разработчиком, еще будучи студентом. Он выбрал язык программирования Java и начал его изучать. Тренировался на простых вещах:
Сначала весь код его мини-программ хранился в одном файле — Main.java. Чтобы запустить приложение, достаточно было дважды кликнуть этот файл. И всё!
Потом Вася освоил Page Object Pattern и стал разносить логику по разным классам. Но всё равно это были простые программы, и для запуска оставался главный класс.
А потом Вася. Устроился на работу. Да-да, зеленым новичком, и такое бывает! Старший разработчик Николай на собеседовании разглядел в нем потенциал. Так Вася стал джуниор-разработчиком в компании ООО «Котики».
Проект в компании большой, с семилетней историй. Он состоит из 6000 классов исходного кода, над которыми трудятся 5 разработчиков.
В первый рабочий день Николай подошел к Васе и стал рассказывать:
— Наш код хранится в git. Знаешь, что это такое?
— Ага, система контроля версий!
— Да. Вот тебе ссылочка, скачивай.
Вася скачал. Только вот. Что делать дальше? Какой из 6000 классов запустить, чтобы пощупать приложение?
Николай только ухмыльнулся:
— Нет, так оно только для мелких проектов работает. А тебе нужно:
скомпилировать проект — из исходных текстов получить файлы классов с байт-кодом (которые потом будет исполнять JVM);
объединить вот эти классы в библиотеку Search.jar;
объединить вот эти классы в библиотеку Clean.jar;
объединить вот эти классы в библиотеку Update.jar;
объединить вот эти классы в библиотеку Report.jar;
объединить вот эти классы в библиотеку Link.jar;
Вася в шоке выкатил глаза и промямлил:
— Ээээ, подожди. Мне это выучить надо?
— В учебных проектах тебе не надо заморачиваться. Запустил конкретный класс, и всё работает. Ну, может, еще одну-две библиотечки собрал, но это тоже несложно.
Но когда приложение растет, растет и список действий. Вручную его выполнять смысла нет — скука, да и только. К тому же человек легко может ошибиться, а в итоге получим неработающее приложение.
Поэтому эту работу автоматизируют. Можно написать скрипт сборки на коленке, но зачем, если уже есть стандартные сборщики? Скажем, для java это ant, maven, gradle. У нас используется maven, почитай пока о нем.
Сборщик уже настроен, так что тебе достаточно зайти через командную строку в директорию проекта и написать команду:
А дальше он сам всё сделает. На выходе получим cats.war. Это и есть наше приложение, которое мы потом подложим на сервер wildfly, чтобы его запустить.
— Ага, хорошо, спасибо!
Николай ушел, а Вася завороженно смотрел в экран, где в командной строке работал maven. Быстро-быстро бежали буквы по экрану. И вот, наконец, сборщик остановился. Он написал «BUILD SUCCESS». Значит, всё прошло хорошо. И в нужной директории Вася нашел архив «cats.war».
Пока Николая не было, Вася успел нагуглить это новое слово: «maven». И даже смог найти в проекте скрипт сборки, и начал разбираться, что конкретно там происходит. Всё-таки не зря его взяли на работу! Это отличное качество разработчика (да и не только его) — гуглить и копать самому, а не сидеть сложа ручки в ожидании ментора.
Когда Николай вернулся, он подытожил то, что Вася узнал:
— Когда разработчик пишет код — он просто создает набор файликов с текстом. Чтобы эти файлики превратились в работающее приложение, код нужно скомпилировать и запустить.
Что нужно сделать с кодом-источником:
объединить классы в файл JAR или другую библиотеку;
установить набор зависимостей;
запустить конкретный класс или несколько классов.
И только после всех этих манипуляций у нас появляется ПО. Набор манипуляций зависит от конкретного проекта, но чем сложнее проект, тем больше действий надо сделать.
А если задача повторяется снова и снова, она становится первым кандидатом на автоматизацию. Ведь нам нужно что? За один шаг получить работающий проект! Этим и занимаются системы сборки!
— О, стой! Так в IDEA (среда для написания кода) же кнопка «Build» есть. Она ведь тоже билдит, то есть собирает код! Да? Это аналог maven-а?
— Не совсем. Это кнопка:
компилирует код — проверяет его на наличие простых синтаксических ошибок вида «забыл поставить точку с запятой в конце команды»
собирает нужные ресурсы (файлы конфигов и подобные) в одну папочку, из которой уже можно запускать программу
— Так если она все собирает и можно программу запускать, зачем maven нужен?)
— Она не собирает само приложение, так как не знает всех зависимостей. Поэтому нужна отдельная программа-сборщик кода.
— А в чем тогда смысл собирать ресурсы?
— Ну, например, для запуска автотестов. Когда мы их запускаем, там не используется полностью варник (приложение cats.war). Там вызываются конкретные функции + используются конкретные ресурсы типа справочника телефонных номеров.
Разработчик исправил код и нажимает «Build». Это обновляет ресурсы, которые используются в тестах. А если тебе нужен варник приложения, то собираешь maven-ом (ну или аналогом).
— Диалог правильный, но это подход 10-летней давности. Сейчас всё делегируют maven/gradle. В IDE даже галочка есть отдельная для этого. А уже в maven/gradle делаются гранулярные цели для каждой задачи.
— А вообще главное отличие сборщика от IDE — сборщик можно запустить из командной строки, на любом окружении, независимо от среды разработки + в CI/CD системе (TeamCity, Jenkins и тп). Это воспроизводимый билд.
То есть при желании IDEA можно настроить, чтобы она все это делала. Прописать все зависимости и другое, но это будет нерасширяемо.
Как работает сборщик
Сборщики работают примерно одинаково. Базовый функционал:
компилировать код (проверять на простейшие синтаксические ошибки)
создавать и удалять директории
Есть и более продвинутые программы, которые также позволяют автоматически извлекать зависимости в библиотеке или автоматизировать тестирование.
Как сборщик поймет, что именно от него нужно? Благодаря скрипту компоновки. В нем разработчик описывает, что конкректно сборщик должен делать.
Давайте посмотрим, как такой скрипт выглядит, на примере Ant. Ant — инструмент компоновки для Java-проектов.
Файл компоновки Ant — это XML-документ. Он разбит на 4 основные части:
В каждом файле компоновки есть проект, и хотя бы одна (умолчательная) цель. Внутри цели находятся задачи — что именно системе надо сделать, если вызвана данная цель.
Проект
Всё в файле является частью проекта. Поэтому тег
является корневым в скрипте:
default — умолчательная (дефолтная) цель, срабатывающая при запуске скрипта.
Внутри проекта уже находится все остальное — цели, которых мы хотим достичь, и конкретные действия для их достижения.
По-хорошему, у проекта должно быть имя и умолчательная цель. Хотя согласно официальной документации, эти параметры не являются обязательными.
Дефолтная цель сработает по умолчанию, если при запуске ant не указана другая. Поэтому в ней должно быть все нужное для работы проекта.
Свойства
Свойства Ant похожи на константы. Один раз указали значение, и используем в скрипте хоть в 20 местах. А если значение изменилось, исправить надо будет одно место, а не двадцать. Сюда очень хорошо выносить версии продукта и зависимых библиотек, а также пути к директориям.
Записываются свойства в теге
У каждого свойства есть:
значение — value, или место — location (если указываем путь к директории)
Цель — это то, что мы хотим получить от сборщика. Краткое название для «я хочу скомпилировать проект» или «я хочу создать все нужные папочки».
Цели записываются в тегах :
Основные атрибуты цели:
name — имя цели, которое мы будет указывать в командной строке, поэтому лучше делать его коротким. Обязательный параметр.
description — описание цели. Выводится при запросе информации по проекту.
depends — от кого эта цель зависит. То есть какую цель надо запустить перед выполнением текущей. Необязательный параметр
В примере цель ”build” зависит от цели ”compile”. Мы не можем начать сборку билда, пока не скомпилировали его. Поэтому, если мы вызываем ant с целью сборки билда, то он:
Выполнит цель ”compile”
Выполнит цель ”build”
То есть за один присест можно выполнить сразу несколько целей, если прописать их в блоке depends. В данном случае мы вызвали одну цель, а выполнили две. Можно ли выполнить больше? Можно ли указать сразу несколько зависимостей? Да! Для этого надо записать имена целей через запятую в блоке depends:
Обратите внимание на граф вызова целей. Исходно мы хотим выполнить цель D. Читая атрибут depends, можно подумать, что первой будет вызвана цель C, потом B, и потом A. Это не так! Читать блок depends надо так:
Таким образом, сначала мы вызываем цель A, потом B, и только потом C. То есть фактически читаем справа налево этот атрибут.
У цели могут быть и другие атрибуты. Например, условие «if». Но подробнее о них читайте в официальной документации Ant — статья «Targets».
Цель по умолчанию
Какой должна быть цель по умолчанию? Должна ли проводиться компиляция, группировка, генерирование документации или все вместе?
Это зависит от проекта. Если кто-то берет код с сервера, что он будет с ним делать? Захочет посмотреть на проект и будет ожидать, что он запустится за один шаг? Если так, целью по умолчанию будет выполнение всех операций.
Но для выполнения всех операций надо использовать ключи шифрования, установщики типа InstallShield и т.д. Стоит ли париться? Многие ставят целью по умолчанию вывод справки по проекту, чтобы новые люди сообразили, что им нужно делать.
Задачи
Задача — это конкретное действие, которое нужно выполнить, чтобы достичь поставленной цели. Например, создать директорию, скопировать файлы, скомпилировать Java-код.
В Ant задача обычно отражает определенную команду: «javac», «mkdir» или даже «javadoc». Именно эта команда и будет названием тега:
Внутри цели может быть одна задача. Например, для компиляции проекта нам нужно скомпилировать java-код в конкретной директории:
При вызове цели compile будет вызвана задача javac. Она компилирует код java в srcdir и складывает классы в destrdir.
Внутри цели может быть несколько задач, как одинаковых, так и разных. Например, мы хотим создать все нужные проекту директории, а их несколько. Вызываем несколько раз задачу mkdir. Она создает директорию, определяемую атрибутом dir:
При вызове цели init у нас будут созданы 2 директории — ”bin” и ”lib”.
Возможно, нам надо не только создать директорию, но и подложить в нее какой-то файл. Тогда задачи будут разные.
Стандартная версия Ant содержит более 150 заданий. Вот некоторые из них:
echo – вывод сообщений в консоль
mkdir – создание директорий
copy — копирование файлов
delete – удаление файлов и директорий
move – перемещение файлов и директорий
replace — замещение фрагментов текста в файлах
javac – компиляция Java–кода
java – запуск class и jar файлов
jar – создание jar файла
junit – запуск тестов
exec — выполнение внешней команды
zip — создание архива в формате Zip
Доп ссылки
Writing a Simple Buildfile — официальная дока на английском
Как запустить сборку
Все зависит от сборщика. Но обычно это название сборщика + название цели, которую мы запускаем. Для Ant это выглядит так:
Целей может быть несколько:
Фишка ant в том, что вы можете назвать цель как угодно:
С одной стороны, это звучит даже забавно:
И все вокруг знают, что это означает пересобрать проект. Но такие хиханьки-хаханьки хороши лишь в умеренных дозах. Подумайте сами — если каждую цель назвать как-то «невпопад», то придется просто заучивать эти названия. Что неудобно.
А уж если в коллектив придет новый человек, то ему придется пояснять, почему используются такие загадочные названия и почему ему надо их выучить.
Поэтому обычно используют стандартные названия целей
clean — чистка проекта: удаление файлов заготовок, которые остаются после компиляции. Приводит проект к виду, в котором он хранится в репозитории
compile — компиляция исходного кода
test — запуск тестов
install — установка пакетов в локальный репозиторий, чтобы использовать зависимости от других проектов локально
Посмотрим на примере, который можно взять и пощупать — в проекте folks используется сборщик maven. А в статье «Как собрать проект и запустить тесты» (в старой версии, там возникли проблемки со сборщиком после обновления и команды заменили) мы видим такие команды:
Эти команды — типовые для maven-а. Давайте разберемся, что они означают.
Это сокращение от maven. Название сборщика, к которому мы обращаемся.
Первое слово, которое вы пишете в командной строке — это вызов команды. Это может быть путь к самой программе вида:
А может быть просто название команды:
В этом случае система (я говорю про винду) полезет в PATH и проверит: а есть ли там такое? Если есть, то запустит программу и по короткой команде. Подробнее про PATH можно почитать здесь.
Когда вы устанавливаете maven (ant или любой другой сборщик), вы прописываете путь к нему в переменную PATH. По крайней мере, в инструкции по установке есть такой пункт. Именно благодаря этому пункту команда «mvn» в командной строке начинает работать.
По сути, тут все то же самое, что и в ant — мы пишем название сборщика (mvn) и те цели, которые мы хотим запустить. Точнее, фазы. В maven это называется phases, и набор фаз вполне определенный. В этом отличие сборщиков, ant более гибкий и цели мы можем настраивать и называть так, как захотим. В maven не можем.
clean
В обеих командах сначала вызывается фаза clean. Она нужна для того, чтобы очистить созданные другими сборками артефакты. Так как я тестировщик, то объясню с точки зрения тестирования.
Допустим, мы запускаем автотесты. Их можно запускать пачкой (вообще все или из конкретной папки), а можно запускать один конкретный. Во время прогона система создает артефакты — это может быть состояние базы данных или поискового индекса, временные файлики, или что-то еще.
Теперь, когда мы просто запускаем тест, без clean, система переиспользует созданные артефакты. И это хорошо! Потому что так тесты гоняются намного быстрее. Система уже не тратит время на повторное создание артефактов.
Это как если у вас перед готовкой пустой холодильник или полный. Если пустой — надо идти в магазин. Если вы уже вчера туда сходили и продукты все есть, можно сразу приступать к готовке!
Да, переиспользование артефактов — это хорошо. Но иногда их надо почистить. Вот, скажем, если у вас яйца протухли, то и омлет станет отравой, и шарлотку есть будет нельзя. Любое блюдо будет испорчено из-за одного плохого ингредиента. Баг в исходнике «сломал» готовый продукт!
Что мы делаем в таком случае? Испорченные яйца выкидываем, идем в магазин за новыми. Примерно так и работает clean — чистит наш холодильник. Единственная проблема — она чистит всё. Удалять так удалять!
Фаза удаляет все артефакты, созданные предыдущими сборками. То есть система возвращается в состояние на момент забора данных из репозитория. Плюс твои локальные изменения кода (именно исходного кода, а не сгенеренных по нему артефактов).
Фазу можно и не вызывать, но это надо делать с полным осознанием своих действий. Чтобы потом не тупить над тем, почему это вдруг разработчик исправил баг и у него все хорошо, а у вас до сих пор плохо.
Понимаете, часто повторяющиеся действия мы делаем на автомате, не задумываясь о них. Допустим, что мы привыкли утром очищать свой репозиторий и прогонять
А потом, в процессе дня, мы фазу clean уже не вызываем:
Так вот, в коде обнаружился баг, который из кода «переехал» в артефакты. Разработчик баг исправил, даже проверил у себя локально — работает! Отдает вам, вы пересобираете проект — не работает! Как так?? Вы же пересобрали! Ведь вызвали же фазу «install».
При этом иногда над простыми ошибками тупят дольше всего. Разработчик снова ковыряется в коде, тратит время — должно же работать. Вы снова собираете — нет, не работает! И только когда разработчик приходит посмотреть, что именно вы делаете, он обращает внимание на команду:
— Стой! Ты же clean не делаешь!
— Ну да, я его только по утрам вызываю.
Это называется «делать на автомате», не задумываясь о своих действиях. Если вы не хотите думать над командой по сборке, то всегда вызывайте clean, не прогадаете. Да, сборка чуть дольше будет идти, но вы точно не огребете такую проблему.
Аналогичная ситуация может возникнуть при прогоне автотестов. Прогнали один тест — все хорошо, он работает. Прогоняете другой — он падает, причем очень странно. Тест пишет, что ожидает «Иванова», которого в вашем тесте нет вообще! Откуда же он взялся??
Да просто первый тест не почистил базу за собой! И Иванов остался в артефактах. А вы не вызвали фазу clean для экономии времени. Отсюда и баг. Поэтому при подозрительных падениях тестов из серии «откуда он взял эти данные» стоит перепрогнать тест с фазой clean.
install
Это сборка продукта. Folks нельзя развернуть и потыкать, но если бы можно было, то это выглядело бы именно так:
Скачали исходный код продукта
Выполнили команду «mvn clean install»
Забрали готовый билд в определенной папочке!
Хотя по сути своей фаза install ничего не собирает. Она публикует собранный артефакт в локальном репозитории. Смотрите — в maven есть свой жизненный цикл (подробнее см в статье «Maven in 5 Minutes», раздел «Maven Phases»):