Комментарии 12
Сам активно использую груви в качестве основного скриптового языка — Grape позволяет по-быстрому и страничку скачать/отпарсить, и данные в базу залить, и по файловой системе пройтись.
Правда, я использую обычные скрипты #!/usr/bin/groovy и у меня всё работает. В чем преимущество запуска через java -jar?
Правда, я использую обычные скрипты #!/usr/bin/groovy и у меня всё работает. В чем преимущество запуска через java -jar?
Как лютый хак при
можно предварительно натравливать URLClassLoader на ivy jar-ник в maven central, а затем Grape.grab.
Caused by: java.lang.ClassNotFoundException: org.apache.ivy.Ivy
можно предварительно натравливать URLClassLoader на ivy jar-ник в maven central, а затем Grape.grab.
maven central
Вы имели в виду кеш maven в локальной файловой системе?
Для этого хака Ivy должен был запрашиваться каким-либо приложением раньше чем вам он понадобиться, чтобы оказаться в этом кеше
Можете пожалуйста готовый пример предложенного решения привести, чтобы запустить то же самое с «чистым» groovy?
3 Мб оверхеда, да ещё и выковырянных из другого проекта. Вы же, как я понял, всё равно используете maven-указаение зависимостей и его артефакты. Ivy (https://mvnrepository.com/artifact/org.apache.ivy/ivy/2.4.0) занимает всего 900Кб и готов к использованию. В том числе как зависимость проекта, в котором вы собираете единый артефакт.
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
Добрый вечер! Первая аналогия что пришла в голову в связи с вашим аргументом про разницу в размере библиотеки в 3 раза: «Зачем играть в Quake4 когда Doom2 в Nдцать раз меньше и его можно записать на флоппи-диски!?». Странный критерий оценки ПО, когда различается не только объем, но качество и функциональность.
Если вам интересно, посмотрите на пример AlarmSystem.groovy. Там используется не только разрешение зависимостей с помощью aether, но и динамическая загрузка класса с помощью MavenClassLoader из этой же библиотеки. Функциональные возможности сборки Groovy не ограничиваются этим…
Если вам интересно, посмотрите на пример AlarmSystem.groovy. Там используется не только разрешение зависимостей с помощью aether, но и динамическая загрузка класса с помощью MavenClassLoader из этой же библиотеки. Функциональные возможности сборки Groovy не ограничиваются этим…
Это зависит от конечной цели. Не удобно забивать гвозди отверткой…
Если нужен полноценный проект, то Grape возможно не лучший инстурмент для этого. И конечно лучше это делать на gradle. Вы правильно заметили количество действий, что необходимо сделать и еще необходимо написать скрипт сборки. Я не призываю на Grape делать то что делает система сборки проекта)
Если же нужно написать компактный скрипт или решать задачи, похожие на те задачи которые решает AspectJ-Scripting, то Grape — отличный инструмент
Если нужен полноценный проект, то Grape возможно не лучший инстурмент для этого. И конечно лучше это делать на gradle. Вы правильно заметили количество действий, что необходимо сделать и еще необходимо написать скрипт сборки. Я не призываю на Grape делать то что делает система сборки проекта)
Если же нужно написать компактный скрипт или решать задачи, похожие на те задачи которые решает AspectJ-Scripting, то Grape — отличный инструмент
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уличная магия в скриптах или что связывает Groovy, Ivy и Maven?