Gradle фронтенд к мавену [из [java] Почему я не люблю Java]

yroslavasako

кстати, а сейчас mvn все еще используется? есть же gradle, удобно и настраиваемо

Она лишь фронтенд к мавену.

psm-home

кстати, а сейчас mvn все еще используется? есть же gradle, удобно и настраиваемо
Она лишь фронтенд к мавену.

Парад экспертизы на форум.локал продолжается. В каком именно смысле gradle является фронтендом к maven?

yroslavasako

Сам я градлом не пользовался. Но большая часть библиотек распространяется через maven репозитории. И содержит how-to по включению их в проект. Так вот, один и тот же мавен используется везде, меняется только синтаксис.
см. пример guava

To add a dependency on Guava using Maven, use the following:



<dependency>

  <groupId>com.google.guava</groupId>

  <artifactId>guava</artifactId>

  <version>18.0</version>

</dependency>

To add a dependency using Gradle:



dependencies {

  compile 'com.google.guava:guava:18.0'

}

Я нахожу их удивительно похожими. С точностью до синтаксиса guava и maven делают одно и то же. И если у пакета будут зависимости, то они будут выкачиваться и в maven и в gradle. И я очень сомневаюсь, что gradle реализовал свой собственной механизм удовлетворения зависимостей, скорее всего она напрямую использует maven для этого.
Опять же я не пользовался gradle и не уверен, но об этом говорит логика. Если происходит что-то другое, будь добр, подтверди это документацией а лучше исходниками.

yroslavasako

Ничего я не офигел. Ты предположил нечто очень странное для программиста, будто кто-то сделал кучу лишней работы. И если ты уж был так уверен, что моё утверждение не верно, то что скажешь о
http://github.com/gradle/gradle/blob/master/gradle/dependencies.gradle
Почему-то gradle зависит от maven. Объясни этот факт, если полагаешь, что градл не пользуется мавеном.

//core:
dependency "org.apache.maven:maven-core:3.0.jar"
dependency "org.apache.maven:maven-compat:3.0.jar"
dependency "org.apache.maven:maven-model-builder:3.0.jar"
dependency "org.apache.maven:maven-model:3.0.jar"
//somewhat core:
dependency "org.apache.maven:maven-artifact:3.0.jar"
dependency "org.apache.maven:maven-repository-metadata:3.0.jar"
dependency "org.apache.maven:maven-plugin-api:3.0.jar"
dependency "org.apache.maven:maven-aether-provider:3.0.jar"
dependency 'org.apache.maven.wagon:wagon-file:2.jar'
dependency 'org.apache.maven.wagon:wagon-http:2.jar'
dependency 'org.apache.maven.wagon:wagon-provider-api:2.jar'
dependency 'org.apache.maven.wagon:wagon-http-shared4:2.jar'

Достали модно-молодёжные хипстеры, которые считают свои технологии новой эрой в программирования, не обращая внимания на основания, их поддерживающие.

danilov

> Она лишь фронтенд к мавену.
Она (она?) не фронтенд к мавену. Она умеет в мевен репах копаться (а также и в некоторых других).
Это отдельная сисетма сборки со своими плюшками и недостатками. Но вообще, выше написали, что это ты должен доказывать, а не тебе.
Если удобно, для пользователя это расширение функционала мавена (с полной заменой синтаксиса). Так что вопрос выбора таки стоит перед людьми

danilov

> Если происходит что-то другое, будь добр, подтверди это документацией а лучше исходниками.
Вот плагин к градлу для микробенчмакров http://github.com/melix/jmh-gradle-plugin
Затащи его в мавен и похавстайся тут.
Вот сравнение http://gradle.org/maven_vs_gradle/
Там же можешь доки почитать

psm-home

Ничего я не офигел. Ты предположил нечто очень странное для программиста, будто кто-то сделал кучу лишней работы. И если ты уж был так уверен, что моё утверждение не верно, то что скажешь о
http://github.com/gradle/gradle/blob/master/gradle/dependen...
Почему-то gradle зависит от maven. Объясни этот факт, если полагаешь, что градл не пользуется мавеном.
//core:
dependency "org.apache.maven:maven-core:3.0.jar"
dependency "org.apache.maven:maven-compat:3.0.jar"
dependency "org.apache.maven:maven-model-builder:3.0.jar"
dependency "org.apache.maven:maven-model:3.0.jar"
//somewhat core:
dependency "org.apache.maven:maven-artifact:3.0.jar"
dependency "org.apache.maven:maven-repository-metadata:3.0.jar"
dependency "org.apache.maven:maven-plugin-api:3.0.jar"
dependency "org.apache.maven:maven-aether-provider:3.0.jar"
dependency 'org.apache.maven.wagon:wagon-file:2.jar'
dependency 'org.apache.maven.wagon:wagon-http:2.jar'
dependency 'org.apache.maven.wagon:wagon-provider-api:2.jar'
dependency 'org.apache.maven.wagon:wagon-http-shared4:2.jar'

Достали модно-молодёжные хипстеры, которые считают свои технологии новой эрой в программирования, не обращая внимания на основания, их поддерживающие.

Эти зависимости связаны с тем, что гредл умеет понимать репозитории/зависимости в формате maven, т. к это практически стандарт. По той же причине гредл по умолчанию использует layout проекта как у maven. При этом всё "мясо" ( объектная модель проекта, жизненный цикл билда, механизм разрешения зависимостей) у гредла своё. Поэтому гредл не является фронтендом для мавена. А хипстеры достали, это точно. Доказывая твое утверждение через зависимости можно дойти до того, что назвать гредл фронтендом любой из них, зачем ограничиваться одним мавеном?

yroslavasako

и что? Я могу обернуть maven в make и у меня будут работать специфичные make средства. Но разрешение зависимостей и их конфликт, на которые тут жаловались останутся на месте, поскольку всю работу с зависимостями gradle перепоручает мавену.

yroslavasako

Эти зависимости связаны с тем, что гредл умеет понимать репозитории/зависимости в формате maven, т. к это практически стандарт.

"практически". Назови собственный стандарт гредла. Его нет. А значит без мавена и его инфраструктуры он не юзабелен.

psm-home

Гредл совместим с мавеном по layout проекта и поддерживает его репозитории (а также репозитории Ivy), и поэтому является фронтендом к maven (и по этой логике, одновременно, является фронтендом к Ivy). Короч понятно, случай клинический, я умываю руки.

luna89

Эти зависимости связаны с тем, что гредл умеет понимать репозитории/зависимости в формате maven, т. к это практически стандарт.

Хороший пример работы со стандартами в джаве. Есть плейнтекстовый формат, описывающий простую структуру данных (название модуля, версия, список зависимостей). Вместо того чтобы взять и распарсить этот простой формат самому (в javascript это была бы одна строчка JSON.parse(data)), надо подключать 20 мегабайт джаров.
Забавно, что все эти градли и мавны являются self-hosted системами - чтобы собрать мавн, надо скачать его зависимости, а для этого нужн мавн. Нужен этап бутстрапа.

yroslavasako

Именно. gradle лишь надстройка над ними. И каждый раз, когда ты им пользуешься в любом проекте с зависимостями, ты на самом деле пользуешься мавеном. Поэтому я совершенно не понимаю твоё противопоставление мавена и гредла. Это всё равно что ntfs и explorer противопоставлять.

Dasar

Из сказанно в треде, я услышал, что:
- Gradle самостоятельная система управления зависимостями.
- Gradle умеет использовать репозиторий мавена, для этого он использует часть библиотек мавена

6yrop

а нахрен вообще специальные мега тулзы для управления зависимостями?
хороших либ очень мало, а плохими зачем пользоваться?

yroslavasako

градл не имеет альтернативы. Одно дело, если бы у неё была своя система. И она умела бы работать ещё с другими. Но своей системы у неё нет.

yroslavasako

а нахрен вообще специальные мега тулзы для управления зависимостями?

потому что так удобнее чем копировать либы в репозитории

хороших либ очень мало, а плохими зачем пользоваться?

Потому что ты можешь написать сам хороших либ. И перед тобой встанет вопрос, как бы эти либы подцепить к собственным проектам. И внезапно оказывается, что идея менеджера зависимостей не так уж и плоха.
А если мы говорим о java, то там множественное число в слове "тулзы" излишне.

6yrop

Потому что ты можешь написать сам хороших либ. И перед тобой встанет вопрос, как бы эти либы подцепить к собственным проектам.

свои тулзы цепляешь самым простым способом с исходниками

yroslavasako

простой, но неудобный.

yroslavasako

Забавно, что все эти градли и мавны являются self-hosted системами - чтобы собрать мавн, надо скачать его зависимости, а для этого нужн мавн. Нужен этап бутстрапа.

Это вообще не проблема. Нашёл нужные jar-ники и накидал в папку, включил её в путь.

schipuchka1

хороших либ очень мало, а плохими зачем пользоваться?

это в шарпе.

psm-home

поскольку всю работу с зависимостями gradle перепоручает мавену

Вот это просто распространение заведомо неверной информации. Гредл сам реализует управление зависимостями и, кроме того, совместим с maven и ivy. web page
Самая ржака в том, что ты не пользовался им и судя по всем даже доку не смотрел, несмотря на это позволяешь себе вещать про то, как все устроено "из общих соображений".

schipuchka1

а нахрен вообще специальные мега тулзы для управления зависимостями?

1. Контроль зависимостей. Если тебе нужно включить в проект реализацию одного протокола, тебе не хочется тащить весь сервер. Системы контроля версий позволяют включить минимальную достаточную часть библиотек.
2. Контроль совместимости. Ты хочешь иметь возможность держать зависимости зависимыми с учётом что они регулярно обновляются.
3. Кеширование и локальное расшаривание. Ты можешь разрабатывать несколькими командами имея общий релизный репозиторий для артефактов.
4. Быстрый старт и компактность - любой человек сможет восстановить весь стейт проекта скачав его текстовую часть (с гит хаба к примеру).

yroslavasako

Информация по твоей ссылке может быть понята двояко.

Transitive dependency management: Gradle gives you full control of your project's dependency tree.

Support for non-managed dependencies: If your dependencies are simply files in version control or a shared drive, Gradle provides powerful functionality to support this.

Support for custom dependency definitions.: Gradle's Module Dependencies give you the ability to describe the dependency hierarchy in the build script.

A fully customizable approach to Dependency Resolution: Gradle provides you with the ability to customize resolution rules making dependency substitution easy.

Full Compatibility with Maven and Ivy: If you have defined dependencies in a Maven POM or an Ivy file, Gradle provides seamless integration with a range of popular build tools.

Integration with existing dependency management infrastructure: Gradle is compatible with both Maven and Ivy repositories. If you use Archiva, Nexus, or Artifactory, Gradle is 100% compatible with all repository formats.

Их можно читать так:
Пункт 1: Мы зависим от третьего мавена, а он уже научился управлять транзитвностью. Мы предоставляем более удобную запись этих опций
Пункт 2: А ещё можно накидать жарников в папку и сказать javac, чтобы он туда смотрел. Мы упрощаем процедуру передачи параметров для javac
Пункт 3: Внутри своего проекта мы можем собирать подпроекты в любой последовательности
Пункт 4: Вот здесь интересно, хочется подробностей.
Пункт 5: Очевидно
Пункт 6: Конечно, ведь для гредла никто не будет строить отдельную инфраструктуру.
Я по-прежнему крепко сомневаюсь, что гредл изобрёл велосипед. Скорее всего он опирается на существующую инфраструктуру целиком. Жду примеров проектов на гредле, которые бы не использовали maven. Ведь он "не нужен".
P.S. [list=1] не работает

psm-home

Жду примеров проектов на гредле, которые бы не использовали maven.

Примеры из доки, вида

 

repositories {

    ivy {

        url "http://repo.mycompany.com/repo" // используется Ivy репо, maven не при чем

    }

}

не подходят?
В доке же кстати прямо сказано, что управление зависимостями своё.
52.1.2. Dependency management and Java

While Maven provides a complete build system, Ivy focuses solely on dependency management.
Both tools rely on descriptor XML files, which contain information about the dependencies of a particular jar. Both also use repositories where the actual jars are placed together with their descriptor files, and both offer resolution for conflicting jar versions in one form or the other. Both have emerged as standards for solving dependency conflicts, and while Gradle originally used Ivy under the hood for its dependency management. Gradle has replaced this direct dependency on Ivy with a native Gradle dependency resolution engine which supports a range of approaches to dependency resolution including both POM and Ivy descriptor files.

Или дока недостаточно авторитетный источник?

yroslavasako

окей. Признаю, был неправ. Навелосипедили своё. Хотя предсказуемо начинали с использования готовых либ.

Оставить комментарий