История изменений

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle. А вот .NET отставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал IDE чтоб она перечитала билд файл (перестроила свои конфиги, обновила classpath, чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно такими как на девелоперских машинах, и в случае обнаружения бага можно быть почти уверенным что проблема в коде проекта а не в сторонней либе. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла), тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle. А вот .NET отставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал IDE чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно такими как на девелоперских машинах, и в случае обнаружения бага можно быть почти уверенным что проблема в коде проекта а не в сторонней либе. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла), тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle. А вот .NET отставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал IDE чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно такими как на девелоперских машинах, и в случае обнаружения бага можно быть почти уверенным что проблема в коде проекта а не в сторонней либе. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла). Тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle. А вот .NET отставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал IDE чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно однозначными как на девелоперских машинах. Чтоб быть совсем уверенным что проблема не в сторонней зависимости. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла). Тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle. А вот .NET отставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал иде чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно однозначными как на девелоперских машинах. Чтоб быть совсем уверенным что проблема не в сторонней зависимости. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла). Тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для управления зависимостями используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle, и это в .NET бесконечно оставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал иде чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно однозначными как на девелоперских машинах. Чтоб быть совсем уверенным что проблема не в сторонней зависимости. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла). Тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.

Ты какую-то хню пишешь. Ты точно кодер? Хотя от вас, DOT NET’чиков, не знаешь что ожидать :)

Уже больше 15 лет в Java мире для подтягивания зависимостей используется Maven и лет 10 назад появился Gradle. Вижу что там вопрос из 2014 года, но тогда уже был даже Gradle, и это в .NET бесконечно оставал в способах управления зависимостями, да и IDE у него была никакая (без ReSharper).

В java проектах никто не привязывается к IDE, вся конфигурация с перечнем зависимых библиотек прописывается в pom.xml (в случае maven) или build.gradle (Gradle соответственно).
Новый проект создаться как maven или gradle проект а потом импортируется в любую IDE (Idea, Eclipse, NetBeans). IDE читает билд файл и производит самоподстройку. Поменял build.gradle или pom.xml – сказал иде чтоб она перечитала билд файл (перестроила свои конфиги чтоб быть в когерентном состоянии).

Кстати, почти везде в java мире в билд файлах версии зависимостей на сторонние библиотеки прописываются абсолютные, т.е. без шаблонов (т.е. 2.3.5 а не 2.3.*) . Чтоб артефакты были точно однозначными как на девелоперских машинах. Чтоб быть совсем уверенным что проблема не в сторонней зависимости. По необходимости зависимости обновляются перед релизами самими девелоперами (на такое заводят минорые задачи на тасктрекере).

И если иногда хотеться все зависимости запихнуть в один JAR, допустим когда сборку нужно передать клиенту в более удобном формате, типа JAR и скрипт для запуска (2 файла). Тогда это делаться через какой-нибудь maven-assembly-plugin. Правда последний раз я такое делал лет 10 назад.