Статья написана для тех, кто умеет писать простейшие программы на 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.
После этого можно попробовать написать в консоли
mvn --version
Если получится, значит maven установлен.
Как структурировать проект для maven
В терминологии maven совокупность файлов с исходным кодом программы, файлов настроек и всего такого называется проектом. Директория, в которой располагаются эти файлы, называется корневой директорией проекта. В дальшейшем я буду обозначать эту директорию как <project>
Как известно, язык программирования java навязывает программисту структуру директорий, которая диктует расположение файлов с классами. Напимер класс с полным именем com.app.HelloWorld должен находиться в файле com/app/HelloWorld.java и никак иначе.
Maven добавляет к этому ограничению ещё одно — исходный код должен находиться в директории <project>/src/main/java. То есть класс com.app.HelloWorld maven будет искать в <project>/src/main/java/com/app/HelloWorld.java
Вот как будет выглядеть этот самый HelloWorld
package com.app;
public class HelloWorld {
public static void main(String[] argv) {
System.out.println("Hello world");
}
}
Как сделать описание проекта
Но просто положить файлы в ожидаемую maven структуру директорий недостаточно. Для сборки проекта необходимо его описание в виде xml документа. Maven будет искать описание в корневой директории проекта в файле pom.xml .
Содержимое минимального файла pom.xml будет примерно следующим.
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com</groupId>
<artifactId>hello-world</artifactId>
<version>1.0-SNAPSHOT</version>
</project>
Что тут было существенно важного и что надо запомнить? Запомнить надо вот эти три строки.
<groupId>com</groupId>
<artifactId>hello-world</artifactId>
<version>1.0-SNAPSHOT</version>
Эти три строки являются идентификатором программы для внешнего мира. Программа, она же результат работы по сборке проекта, в терминологии maven называется артефактом.
Непонятное слово артефакт используется здесь вместо понятного слова программа потому, что результатом работы системы сборки может быть не только собственно программа, но и библиотека или ещё что-нибудь эдакое. Комбинация параметров groupId, artifactId и version уникальна для каждого артефакта. Об уникальности этой комбинации должен позаботиться программист.
Технически, значения этих параметров могут быть любыми, но при их выборе строго рекомендуется соблюдать правила хорошего тона.
groupId
В groupId обычно находится название какого-нибудь пакета. Напомню, что название пакета согласно тем же правилам хорошего тона, должно быть именем веб-домена, владельцем которого является автор пакета, что позволяет худо-бедно обеспечить уникальность названия.
artifactId
В artifactId — строка с именем артефакта, которое придумывает его создатель. Как правило это какое-нибудь слово, иногда с разделителями в виде тире. Например hibernate-annotation-wat. artifactId должны быть уникальны в рамках groupId.
version
Ну и наконец version это версия артефакта, которую надо увеличивать при каждом более-менее значительном изменении. Версия обычно включает цифрры и буквы. Типа 1.0-SNAPSHOT
Как собрать проект
Теперь, когда структура файлов проекта соответствует ожидаемой, а его описание присутствует в файле pom.xml, для того, чтобы собрать проект, осталось только открыть консоль, сменить текущую директорию на директорию проекта и написать в консоли:
mvn compile
После того, как maven закончит свою работу, в директории проекта появится директория target, в которой будет находиться скомпилированный код.
Скомпилированный java код выглядит так же, как исходный, только вместо файлов с расширением java в директориях, соответствующих названиями пакетов, находятся файлы с расширением class, в которых будет уже не исходный код, а код, предназначенный для интерпретации джава-машиной.
То есть теперь этот код можно запустить.
Как запустить проект
Чтобы запустить скомпилированный код, нужно в консоли из этой же директории набрать
mvn exec:java -Dexec.mainClass="com.app.HelloWorld"
После того, как maven перестанет качать всякую дрянь из интернета, где-то перед здоровой табличкой с надписью BUILD SUCCESS, появится строчка Hello World.
Код отработал, всё прошло удачно.
Вот так собирают java программы с помощью системы сборки maven.
Итого
maven ищет код для сборки в директории <project>src/main/java.
Инструкции по сборке maven будет искать в <project>/pom.xml
Результат работы системы сборки называется артефактом.
От программиста требуется задать groupId, artifactId и version
Сборка осуществляется командой mvn compile
Скомпилированный java код выглядит так же, как исходный код, но вместо файлов с расширением java, там будут файлы с расширением class.
- Запустить скомпилированную программу можно командой
mvn exec:java -Dexec.mainClass="com.app.HelloWorld"
Комментарии (62)
smple
05.09.2016 15:37собрать проект mvn build а не compile
poxu
05.09.2016 15:41+1Я не помню такого этапа жизненного цикла у maven. Может быть вы имели в виду package?
smple
05.09.2016 15:54да package, прошу прощение мое общение с maven окончилось 3 года назад но точно помню что compile на выходу jar и war не давал
а чтобы отработал mvn package необходимо указать entity point
а еще лучше mvn deploypoxu
05.09.2016 16:21-2Для того, чтобы объяснить что такое mvn package, нужно объяснить что такое jar и war и, возможно, рассказать про этапы жизненного цикла. По моему, для первого знакомства это слишком много.
Я считаю, что про jar нужно рассказывать в статье про то, как подключить библиотеки, а про стадии жизненного цикла в статье про то, как запустить юнит-тесты.smple
05.09.2016 16:31возможно
но тогда зачем рассказывать человеку о maven если можно использовать javac?
и почему именно maven когда я несколько лет сталкивался с java везде повально перезжали на gradle и maven был только там где это исторически сложилось.
Статья ваша вам, видней, по поводу mvn build да был не прав не так написал, имел ввиду именно package.poxu
05.09.2016 17:40Видимо надо было подробнее остановиться на вопросе о том, зачем нужен maven, когда есть javac.
maven, помимо того, что о чём написано в статье может делать ещё очень многое. Он может скачать используемые в проекте библиотеки, может разложить куда надо ресурсы может запустить юнит тесты. Кроме того, как верно заметил grossws, он позволяет описать проект и этим описанием может воспользоваться любая современная IDE.
Gradle хорош, но он не стандарт индустрии. Без знания maven пока что обойтись не получится.
smple
05.09.2016 17:48да именно об этом я и хотел сказать что maven здесь не до конца раскрыт, для чего может применяться и как его применять и в чем он именно может помочь, просто мне не удалось это понятно изложить.
про gradle возможно(сколько людей столько и мнений)
и знаю что maven central repository стандарт де факто, который кстате в gradle используется.
grossws
05.09.2016 18:28Gradle хорош, но он не стандарт индустрии. Без знания maven пока что обойтись не получится.
Не соглашусь с первой частью, но соглашусь со второй.
Насколько я видел по android-проектам,
gradle
там является стандартом de facto для сборки.
В мире же java se, когда используют
gradle
,sbt
,lein
илиant
для библиотек — всё равно генерируют pom (хотя при использовании ant'а это бывает несколько реже), описывающий проект, но не сборку: всякие вещи типаproject/distributionManagement
,project/scm
,project/mailingLists
и т. п. Например, см. фрагмент из sbt'шных скриптов akka.poxu
05.09.2016 18:40+1Вы не смотрели эпик баттл между gradle, maven и svt? Там Барух Садогурский (один из адептов gradle и groovy) говорит, что gradle хорошо, но для кровавого энтерпрайза не готов потому, что слишком гибок.
Хотя про андроид я конечно немного забыл :)
grossws
05.09.2016 18:45+2И, в качестве project model для IDE, gradle, боюсь, никогда не потянет в силу той же гибкости и динамичности.
Той же idea приходится исполнять build.gradle на каждый чих при его изменениях, и с десятком зависимостей и без модулей/плагинов это уже становится не менее дорогой операцией, чем изменение зависимостей в maven-проекте с парой-тройкой сотен транзитивных зависимостей и десятком профилей сборки.
guai
05.09.2016 20:02это скорее недоработки со стороны идеи. Если юзаете plugin: 'idea', а не полагаетесь на стандартный эскпорт, можно сократить время перегенерации проекта так:
task ideaOnly {
finalizedBy allprojects*.tasks*.idea
doFirst {
allprojects*.tasks.sum().findAll { !it.name.startsWith('idea') }*.enabled = false
}
}
часто его перегенерить не нужно, только при изменении зависимостей и добавлении модулейgrossws
05.09.2016 20:39Для maven'а существовали (и местами существуют) плагины для генерации проекта под конкретную ide (типа m2e), но использование их, а равно описываемого вами генератора для проекта, имеет один фатальный недостаток: это дополнительное ручное действие, которое надо не забыть сделать после модификации
pom.xml
/build.gradle
.
Рано или поздно оно забывается, а дальше — happy-debug. Ловля проблем с неконсистентными версиями зависимостей — очень неприятное развлечение.
guai
06.09.2016 11:23вы меня натолкнули на мысль повесить это на пулл из системы контроля версий. когда я сам что-то меняю, ну понятно, что надо пересобрать, а когда кто-то, тут не помешает автоматом.
grossws
05.09.2016 16:22+1maven package
по умолчанию (приpackaging=jar
) соберёт jar без зависимостей и запускаться он не будет. Чтобы он запускался надо сделать одно из двух:
- собирать uberjar (с помощью assembly/shade/jarjar/onejar) с указанием
Main-Class
в манифете (можно сделать, например, черезplugin/configuration/archive/addManifestEntries/mainClass
в рамках maven-jar-plugin/maven-shade-plugin или в assembly дескрипторе) - собирать jar+deps (можно использовать к
mainClass
добавитьaddClasspath
плюс опциональноclasspathPrefix
и сложить зависимости в classpath prefix с помощью maven-dependency-plugin'а.
Оно может работать автоматически, если настроено в parent pom'е, но в корневом parent pom'е (который используется по умолчанию) этого нет. Ниже примеры из моего parent'а, которые я использую для сборки uberjar'ов и standalone jar + libs для случаев типа embedded jetty + weld (реализация CDI), которые не работают в режиме uber jar'а либо требуют дополнительной хитрой настройки для работы.
Любой из вариантов ниже (
plugin
и ниже по дереву) можно скопировать вproject/build/plugins
.
uberjar<!-- uberjar --> <profile> <id>uberjar-assembly</id> <activation> <file> <exists>.uberjar-assembly</exists> </file> </activation> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <configuration> <finalName>${project.build.finalName}-uber</finalName> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>${mainClass}</mainClass> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" /> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>reference.conf</resource> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.handlers</resource> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.schemas</resource> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.ApacheLicenseResourceTransformer" /> <transformer implementation="org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformer"> <addHeader>false</addHeader> </transformer> </transformers> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile>
Наличие в проекте файла
.uberjar-assembly
подключит этот профиль и он будет генерировать jar с classifier'омuber
, сконфигурированный для запуска черезjava -jar
. Требует наличие в проекте propertymainClass
.- собирать uberjar (с помощью assembly/shade/jarjar/onejar) с указанием
fishca
05.09.2016 15:37Вот тут вроде описано как собрать. Этого не достаточно?
poxu
05.09.2016 15:40По ссылке статья о том, как собрать код на java, не используя системы сборки. Я делал акцент на maven. Конечно таких руководств тоже много. Возможно пользоваться моим кому-нибудь будет проще, чем каким-то другим.
manefesto
05.09.2016 15:47Maven позволяет разруливать нависимости
Цена на самом деле не велика, правильно настроенный pom.xmlpoxu
05.09.2016 15:48Про это я хочу написать отдельную статью. Благо тема, если её раскрывать полностью, заслуживает чуть ли не книги.
manefesto
05.09.2016 15:53А стоит ли? Мне кажется что maven своего рода инструмент как git, выполняет свою задачу на отлично.
Но на самом деле если сделать как https://git-scm.com/book/ru/v1/, то это будет весьма похвальноpoxu
05.09.2016 16:05Я думаю, стоит. Существующие руководства нередко делают акцент на том, как что-то сделать без объяснения что собственно происходит. Например, мне кажется, что в случае с библиотеками нужно сначала объяснить что такое библиотека, а потом уже коротко написать, как её подключить. И этим ограничиться, чтобы информации было не слишком много за один раз.
grossws
05.09.2016 15:55+2Особенно весело, что хорошая книга уже есть. Это даже без учёта maven by example.
В общем, я бы посоветовал новичкам изучать maven по этим двум книжкам, то статьи по мавену на хабре, к сожалению, в большинстве своём поверхностны и разные авторы по глубине охвата останавливались не сильно дальше данной статьи.
poxu
05.09.2016 16:16Я специально остановился на абсолютном минимуме. Тем, кто хочет научиться пользоваться maven этой статьи конечно недостаточно. Она предназначена для тех, кто хочет понять зачем нужен мавен и провести с ним первое знакомство.
grossws
05.09.2016 16:25+2Ну я в фазе новичка бы из этой статьи не понял зачем нужен
maven
. Т. к. главное — что maven — это проектная модель — здесь не описано. Ну и что она включает минимально, в общем, тоже.poxu
05.09.2016 16:33Про то, что в maven есть такая сущность как проект — есть. Про структуру проекта в maven тоже есть. Минимальный помник есть. Что означают обязательные строки в этом помнике — есть. Есть даже про то, что IDE может создать проект в собственном формате на основме pom.xml, но наверное на этом надо было сделать больший акцент.
Что ещё, по вашему мнению, нужно было добавить к минимуму?
MacIn
05.09.2016 18:22+1Зачем нужен maven, проектная модель и т.д.
Вы показали, как при помощи этого микроскопа забить гвоздь, который можно забить javac ом, но не показали, зачем он, maven, нужен вообще. Мне, как новичку, непонятно, а зачем надо делать вот так, именно так. Зачем структурировать проект именно таким образом и т.д.poxu
05.09.2016 18:35-1Есть объяснение, зачем нужны систем сборки вообще. Оно очень короткое. Я опасаюсь, что если сделать его длиннее, то потеряется фокус статьи.
MacIn
05.09.2016 21:17Без претензий, я просто задумался, как, например, я бы объяснил, зачем нужен make и makefile'ы, если мы можем собрать проект из Visual Studio. Я бы взял простой случай из DDK или что-то аналогичное, где используется, скажем, некоторое количество модулей на ассемблере, несколько модулей на языке С, объяснил бы, как это будет строиться, как почистится мусор, как определится, что нужно откомпилировать, и как все соберется. А потом показал бы дооолгий и нудный путь того же самого, но руками.
mihmig
05.09.2016 16:37Пользуясь случаем хочу спросить:
Как можно избежать передеплоя всего war-файла, если измеился только один class-файл?
Эклипс как-то ругнулся на Ctrl+S что, мол "… не поддерживаю hot redeploy..." но я не понял что ему нужно…
grossws
05.09.2016 17:25+2Если для разработки, то можно использовать dcevm. Если для production'а, то есть штуки типа rebel'а, но не стоит ожидать, что это будет стоить сколь-либо гуманно.
PolyAkaMorph
05.09.2016 17:31+2А зачем запускать с помощью мавена? И можно ли как-то сделать из class exe-файл, что бы без консоли и батников запускать?
poxu
05.09.2016 17:35Запускать с помощью мавена не обязательно, но в статье акцент на использование мавена и поэтому я решил привести пример запуска с его помощью.
exe файл сделать вроде бы можно, но я не знаю как. Эта тема далеко за гранью рамок статьи. Можно сделать jar файл, который будет работать как exe, но это тоже в рамки статьи не входит. Коротко, как это сделать, описано grossws вот в этом комментарии.
igor_suhorukov
05.09.2016 17:53+2Можно сделать exe c помощью Excelsior JET. AOT компиляция в gnu gcj была, но проект давно мертв… На днях опубликую статью про запуск java проекта сервисом, ссылку выложу тут.
cypok
06.09.2016 07:45+2Прямо в тему статьи: у нас (Excelsior JET) недавно еще и maven-plugin появился. ;)
j_wayne
06.09.2016 10:07+2Есть стоковый Java FX packager (но только в oracle jdk вроде с 7 версии, в 8 точно есть), он умеет создавать нативные сборки.
https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
Не уверен насчет non-fx аппов — мельком видел, что без UI может глючить. Не знаю так ли это, использовал для Java FX приложения, для сервера особого смысла в принципе и нет.igor_suhorukov
06.09.2016 10:15Спасибо! Интересный способ, не знал.
А как с лицензией на распространения oracle jre со своим приложением?j_wayne
06.09.2016 10:18+1Все нормально, это легальный способ, специально открытый разработчикам.
Подробно не скажу, но есть определенные несложные правила — не менять состав jre, оставить файлы лицензий и т.п.
igor_suhorukov
07.09.2016 13:12Как и обещал статья про запуск java проекта сервисом/демоном: «Превращаем Java/JVM приложение в демона».
fishca
07.09.2016 13:30зловеще звучит :) ;)
igor_suhorukov
07.09.2016 13:36Шутка с бородой «В качестве ОС для компьютера в храме всегда выберут windows. Ведь в windows — иконы и службы, а в linux — демоны и зомби».
webkumo
05.09.2016 20:40+1«Дорогая, в интернете кто-то неправ»…
хотел написать комментарий с кучей замечаний… но решил всё-таки его в личку отправить…
Впрочем пару моментов здесь опишу:
> Сразу скажу, что Java программиста, который не может собрать свою программу из консольки, на работу не возьмут
— вплоть до мидла возьмут. Умение составлять грамотные билд-файл требуется нечасто и 1-2х человек на проект хватает вполне.
> После того, как maven перестанет качать всякую дрянь из интернета
вы вроде мануал пишете? Для новичков? Ну и зачем засорять неокрепшие умы такой фигнёй? Неужели тяжело было написать что-то вроде после того, как мавен скачает зависимости и инструменты, определённые в проектном файле (а также maven-exec-plugin, к которому вы и обратились командой exec:java)"
А ещё можно было рассказать, что можно разом mvn compile exec:java -Dexec.mainClass=«com.app.HelloWorld»poxu
06.09.2016 09:05Спасибо за рекомендации. Я думаю, что то, что вы написали в личку нужно было писать в коментарии. Это интересно всем, не только мне.
вы вроде мануал пишете? Для новичков? Ну и зачем засорять неокрепшие умы такой фигнёй?
Мой подход к тому, что такое "засорять" отличается от вашего. Добавлять в статью термины зависимости, инструменты и плагин — когда они в ней по сути не используются — это на мой взгляд неправильно. Я хотел написать, что мавен будет что-то качать, но это неважно — не обращайте внимание, главное что он запустит код.
Seboreia
06.09.2016 02:36Возможно ламерский вопрос, но что означает слово SNAPSHOT в версиях артифактов?
poxu
06.09.2016 08:39Оно означает, что артифакт нестабилен и может измениться без изменения версии. Мавен понимает, что это может произойти и обновляет артифакт при каждой сборке.
webkumo
06.09.2016 11:23Ещё из особенностей — обычная версия не имеет права изменяться в мавен-репозитории (а вот снепшот — может, потому и идёт проверка при каждой сборке).
lagranzh
06.09.2016 11:27не при каждой. нужно давать опцию '-U'.
poxu
06.09.2016 12:17Действительно не при каждой, это ценное замечание, я сильно упрощаю. SNAPSHOT версии будут обновляться, если с момента предыдущего получения зависимости из удалённого репозитория и до текущего запуска maven прошло больше суток. Интервал можно настраивать через repository->shapshots->updatePolicy.
Опция -U обновит снепшоты принудительно, независимо от интервалов и всего такого.
grossws
06.09.2016 14:18Плюс можно в
repository/snapshots/updatePolicy
указатьalways
. При использовании nexus'а на небольшом расстоянии (в смысле rtt) довольно удобно.
saboteur_kiev
06.09.2016 02:44C 2009 год, https://habrahabr.ru/post/77382/
poxu
06.09.2016 12:20Статья хорошая но носит обзорный характер. В ней коротко раскрыто слишком много вопросов. Я хотел написать статью, посвящённую только одному узкому вопросу.
shurkandak
06.09.2016 09:19Был бы очень интересно читать, если бы в статье было написано о работе с несколькими подпроектами в одном проекте. Ведь maven это могет.
poxu
06.09.2016 12:21Это тема для отдельной статьи, я надеюсь её написать. Но вообще следующую я планирую написать про то, как подключать сторонние библиотеки.
shizo
Ад, конечно.
poxu
Не могли бы вы раскрыть свою мысль? :)
izzholtik
Некоторые проекты, сконфигурированные не иначе как через особо хитрое место, имеют склонность выкачивать всякую дрянь при каждой сборке и не собираться вообще, если интернета нет.
grossws
Это куда более характерно для ant'а, в котором это очень сильно зависит от того как именно написали
build.xml
.mvn -o
и использование внутреннего nexus'а — наше усё.lpre
Вообще-то Ant по умолчанию вообще ничего на тащит из интернета и не требует его. Если Ant-скрипт что-то и тянет оттуда, то это программист своими очумелыми ручками сделал такой custom-таск (ну, или вставил сторонний таск «для улучшения»).
Тянуть что-либо со стороны — это как раз maven (ну и gradle).
Автору: статья расчитана на новичков, не умеющих делать сборку. Почему вы не началим с простейшего срособа собрать «hello world» без сторонних систем сборок? Или это уже не требуется от желающих найти работу?
grossws
Я в курсе. Обычно народ пишет таск для выкачивания зависимостей для сборки и далеко не всегда использует нормальные средства (типа
ivy
, который, собственно, используетсяgradle
иsbt
), которые нормально работают с кэшами и имеют offline режим.poxu
Ну да, тут совершенно согласен. Я вообще сначала думал запустить программу через простой вызов бинарника java. Но потом решил, что раз уж в статье акцент на maven, то надо делать им.